A few more updates, corrections & changes.
The post-halloween document. v0.10
(aka, 2.5 - what to expect)
Dave Jones <[email protected]>
This document explains some of the new functionality to be found in the 2.5
Linux kernel, some pitfalls you may encounter, and also points out some new
features which could really use testing.
Note, that "contact [email protected]" below also implies that you should also
cc: [email protected].
Latest version of this document can always be found at
http://www.codemonkey.org.uk/post-halloween-2.5.txt
Thanks to Andrew Morton, Alan Cox, Alan Willis and others for valuable feedback.
Regressions:
~~~~~~~~~~~~
(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional, and
will probably be converted to use device-mapper.
- Some filesystems still need work (Intermezzo, UFS, HFS, HPFS..)
- A number of network card drivers don't compile currently due to
them needing work to convert them to the new DMA API, and fix to
work around removals of sti()/cli() functions.
Deprecated features:
~~~~~~~~~~~~~~~~~~~~
- khttpd is gone.
- Older Direct Rendering Manager (DRM) support (For XFree86 4.0)
has been removed. Upgrade to XFree86 4.1.0 or higher.
- LVM1 has been removed. See Device-mapper below.
- boot time root= parsing changed.
ramdisks now have ram<n> isntead of rd<n> and cm206 - cm206cd (instead of cm206).
Kernel build system.
~~~~~~~~~~~~~~~~~~~~
- Versus 2.4, the build system has been much improved.
You should notice quicker builds, and less spontaneous rebuilds
of files on subsequent builds from already built trees.
- make xconfig now requires the qt libraries.
- Make menuconfig/oldconfig has no user-visible changes other than speed,
whilst numerous improvements have been made.
- Several new debug targets exist: 'allyesconfig' 'allnoconfig' 'allmodconfig'.
- For infomation: The above improvements are not CML2 / kbuild-2.5 related.
IO subsystem.
~~~~~~~~~~~~~
- You should notice considerable throughput improvements over 2.4 due
to much reworking of the block and the memory management layers.
- Report any regressions in this area to Jens Axboe <[email protected]>
and Andrew Morton <[email protected]>.
- Assorted changes throughout the block layer meant various block
device drivers had a large scale cleanup whilst being updated to
newer APIs.
- The size and alignment of O_DIRECT file IO requests now matches that
of the device, not the filesystem. Typically this means that you
can perform O_DIRECT IO with 512-byte granularity rather than 4k.
But if you rely upon this, your application will not work on 2.4 kernels
and will not work on some devices.
VM Changes
~~~~~~~~~~
- Version zero swap partitions are no longer supported (everything is
using v1 now anyway - rerun mkswap if in doubt).
Linux 2.0.x requires v0 swap space, Linux v2.1.117 and later
support v1. mkswap(8) can format swap space in either format.
- The bdflush() system call is still there and still just causes
the calling process to exit. This strangeness is presumably there
to support people whose initscripts are trying to start the obsolete
'update' daemon. It's likely this will become deprecated and usage of
this will start logging messages to syslog.
- The actual 'reverse mappings' part of Rik van Riel's rmap vm was merged.
VM behaviour under certain loads should improve.
- VM misbehaviour should be reported to [email protected]
- The VM explicitly checks for sparse swapfiles, and aborts if one is found.
Kernel preemption.
~~~~~~~~~~~~~~~~~~
- The much talked about preemption patches made it into 2.5.
With this included you should notice much lower latencies especially
in demanding multimedia applications.
- Note, there are still cases where preemption must be temporarily disabled
where we do not. If you get "xxx exited with preempt count=n" messages
in syslog, don't panic, these are non fatal, but are somewhat unclean.
- Report such cases (and any other preemption related problems) to
[email protected]
Process scheduler improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Another much talked about feature. Ingo Molnar reworked the process
scheduler to use an O(1) algorithm. In operation, you should notice
no changes with low loads, and increased scalability with large numbers
of processes, especially on large SMP systems.
- Robert Love wrote various utilities for changing behaviour of the
scheduler (binding processes to CPUs etc). You can find these tools at
http://tech9.net/rml/schedutils
- Regressions to [email protected] and [email protected]
Input layer
~~~~~~~~~~~
- Possibly the most visible change to the end user. If misconfigured,
you'll find that your keyboard/mouse/other input device will no longer work.
2.5 offers a much more flexable interface to devices such as keyboards.
- The downside is more confusing options.
In the "Input device support" menu, be sure to enable at least the following.
--- Input I/O drivers
< > Serial i/o support
< > i8042 PC Keyboard controller
[ ] Keyboards
[ ] Mice
(Also choose the relevant keyboard/mouse from the list)
- If you find your keyboard/mouse still don't work, edit the file
drivers/input/serio/i8042.c, and replace the #undef DEBUG
with a #define DEBUG
When you boot, you should now see a lot more debugging information.
Forward this information to Vojtech Pavlik <[email protected]>
- If you use a KVM switcher, and experience problems, booting with the boot
time argument 'psmouse_noext' should fix your problems.
- Users of multimedia keys without X will see changes in how the kernel
handles those keys. People who customize keymaps or keycodes in 2.4
may need to make some changes in 2.5
PnP layer
~~~~~~~~~
- Support for plug and play devices such as early ISAPnP cards has
improved a lot in the 2.5 kernel. You should no longer need to
futz with userspace tools to configure IRQ's and the likes.
- This code is very young, and needs more work, but is more
actively maintained than the previous ISAPnP work.
- Report any regressions in plug & play functionality to
Adam Belay <[email protected]>
ALSA
~~~~
- The advanced linux sound architecture got merged into 2.5.
This offers considerably improved functionality over the
older OSS drivers, but requires new userspace tools.
- Several distros have shipped ALSA for some time, so you
may already have the necessary tools. If not, you can find them
at http://www.alsa-project.org/
- Note that the OSS drivers are also still functional, and
still present. Many features/fixes that went into 2.4 are still not
applied to these drivers, and it's still unclear if they will
remain when 2.6/3.0 ships. The long term goal is to get everyone
moved over to (the superior) ALSA.
procps
~~~~~~
- The 2.5 /proc filesystems changed some statistics, which confuse
older versions of procps. Rik van Riel and Robert Love have
been maintaining a version of procps during the 2.5 cycle which
tracks changes to /proc which you can find at http://tech9.net/rml/procps/
- Alternatively, the original procps by Albert Cahalan now supports
the altered formats since v3.0.5, but lags behind the bleeding edge
version maintained by Rik and Robert. -- http://procps.sf.net/
- The /proc/meminfo format changed slightly which also broke
gtop in strange ways.
Framebuffer layer
~~~~~~~~~~~~~~~~~
James Simmons has reworked the framebuffer/console layer
considerably during 2.5. Support for some cards is still
lagging a little, but it should be functionally no different
than previous incarnations.
IDE
~~~
- The IDE code was subject to much criticism in early 2.5.x, which
put off a lot of people from testing. This work was then subsequently
dropped, and reverted back to a 2.4.18 IDE status.
Since then additional work has occured, but not to the extent
of the first cleanup attempts.
- Known problems with the current IDE code.
o Simplex IDE devices (eg Ali15x3) are missing DMA sometimes
o Serverworks OSB4 may panic on bad blocks or other non fatal errors
o PCMCIA IDE hangs on eject
o Most PCMCIA devices have unload races and may oops on eject
o Modular IDE does not yet work, modular IDE PCI modules sometimes
oops on loading
o Silicon Image controllers give really bad performance currently.
IDE TCQ
~~~~~~~
- Tagged command queueing for IDE devices has been included.
- Not all combinations of controllers & devices may like this,
so handle with care.
READ AS: ** Don't use IDE TCQ on any data you value.
- If you didn't choose the "TCQ on by default" option, you can enable
it by using the command
echo "using_tcq:32" > /proc/ide/hdX/settings
(replacing 32 with 0 disables TCQ again).
- Report success/failure stories to Jens Axboe <[email protected]> with
inclusion of hdparm -i /dev/hdX, and lspci output.
SCSI
~~~~
- Various SCSI drivers still need work, and don't even compile.
- Various drivers currently lack error handling.
These drivers will cause warnings during compilation due to
missing abort: & reset: functions.
- Note, that some drivers have had these members removed, but still
lack error handling. Those noticed so far are ncr53c8xxx, sym53c8xx and inia100
v4l2
~~~~
- The video4linux API finally got its long awaited cleanup.
- xawtv, bttv and most other existing v4l tools are also compatable
with the new v4l2 layer. You should notice no loss in functionality.
- See http://bytesex.org/v4l/ for more information.
Quota reworking
~~~~~~~~~~~~~~~
The new quota system needs new tools.
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/alpha/quota-3.05-pre1.tar.gz
CD Recording
~~~~~~~~~~~~
- Jens Axboe added the ability to use DMA for writing CDs on
ATAPI devices. Writing CDs should be much faster than it
was in 2.4, and also less prone to buffer underruns and the like.
- Updated cdrecord in rpm and tar.gz can be found at
*.kernel.org/pub/linux/kernel/people/axboe/tools/
- With the above tools, you also no longer need ide-scsi
in order to use an IDE CD writer.
- Ripping audio tracks off of CDs now also uses DMA and should
be notably faster. You can also find an updated cdda2wav
at the same location.
- Send good/bad reports of audio extraction with cdda2wav
and burning with cdrecord to Jens Axboe <[email protected]>
- More info at http://lwn.net/Articles/13538/ & http://lwn.net/Articles/13160/
Filesystems:
~~~~~~~~~~~~
A number of additional filesystems have made their way into 2.5.
Whilst these have had testing out of tree, the level of testing
after merging is unparalleled. Be wary of trusting data to immature
filesystems. A number of new features and improvements have also
been made to the existing filesystems from 2.4.
Reports of stress testing with the various tools available would
be beneficial.
NFS
~~~
- Basic support has been added for NFSv4 (server and client)
- Additionally, kNFSD now supports transport over TCP.
- Reports of interoperability with other OS's would be useful.
- Problems to [email protected]
sysfs.
~~~~~~
In simple terms, the sysfs filesystem is a saner way for
drivers to export their innards than /proc.
This filesystem is always compiled in, and can be mounted
just like another virtual filesystem. No userspace tools
beyond cat and echo are needed.
mount -t sysfs none /sys
See Documentation/filesystems/sysfs.txt for more info.
XFS
~~~
The SGI XFS filesystem has been merged, and has a number of userspace
features. Users are encouraged to read http://oss.sgi.com/projects/xfs
for more information.
The various utilties for creating and manipulating XFS volumes can
be found on SGI's ftp server..
ftp://oss.sgi.com/projects/xfs/download/download/cmd_tars/xfsprogs-2.2.2.src.tar.gz
CIFS
~~~~
Support utilities and documentation for the common internet file system (CIFS)
can be found at http://us1.samba.org/samba/Linux_CIFS_client.html
Oprofile.
~~~~~~~~~
A system wide performance profiler has been included in 2.5.
With this option compiled in, you'll get an oprofilefs filesystem
which you can mount, that the userspace utilities talk to.
The userspace utilities for this are very young, and still being developed.
You can find out more at http://oprofile.sourceforge.net/oprofile-2.5.html
Simple boot flag support.
~~~~~~~~~~~~~~~~~~~~~~~~~
The SBF specification is an x86 BIOS extension that allows improved
system boot speeds. It does this by marking a CMOS field to say
"I booted okay, skip extensive POST next reboot".
Userspace tool is at http://www.codemonkey.org.uk/cruft/sbf.c
More info on SBF is at http://www.microsoft.com/hwdev/resources/specs/simp_bios.asp
x86 CPU detection.
~~~~~~~~~~~~~~~~~~
- The CPU detection code got a pretty hefty shake up. To be certain your
CPU has all relevant workarounds applied, be sure to check that it was
detected correctly. cat /proc/cpuinfo will tell what the kernel thinks it is.
- Likewise, the x86 MTRR driver got a considerable makeover.
Check that XFree86 sets up MTRRs in the same way it did in 2.4
(Failures will get logged in /var/log/XFree86.log)
- Early PII Xeon processors and possibly other early PII processors
require microcode updates either from the BIOS or the microcode driver
to handle the O(1) scheduler reliably.
You can find the relevant microcode tools at http://www.urbanmyth.org/microcode/
- Any regressions in both should go to [email protected] Cc: [email protected]
Extra tainting.
~~~~~~~~~~~~~~~
Running certain AMD processors in SMP boxes is out of spec, and will taint
the kernel with the 'S' flag. Running 2 Athlon XPs for example may seem to
work fine, but may also introduce difficult to pin down bugs.
In time it's likely this tainting will be extended to cover other out of
spec cases.
Power management.
~~~~~~~~~~~~~~~~~
- 2.5 contains a more up to date snapshot of the ACPI driver. Should
you experience any problems booting, try booting with the argument
"acpi=off" to rule out any ACPI interaction. ACPI has a much more involved
role in bringing the system up in 2.5 than it did in 2.4
- The old "acpismp=force" boot option is now obsolete, and will be ignored
due to the old "mini ACPI" parser being removed.
- software suspend is still in development, and in need of more work.
It is unlikely to work as expected currently.
CPU frequency scaling.
~~~~~~~~~~~~~~~~~~~~~~
Certain processors have the facility to scale their voltage/clockspeed.
2.5 introduces an interface to this feature, see Documentation/cpufreq
for more information. This functionality also covers features like
Intel's speedstep, and will be extended in time to cover the Powernow
feature present in mobile Athlons. In addition to x86 variants, this
framework also supports various ARM CPUs.
Background polling of MCE
~~~~~~~~~~~~~~~~~~~~~~~~~
The machine check handler has been extended so that it regularly polls
for any problems on AMD Athlon systems. This may result in machine check
exceptions occuring more frequently than they did in 2.4 on out of spec
systems (Overclocking/poor cooling/underated PSU etc..).
LVM2 - DeviceMapper.
~~~~~~~~~~~~~~~~~~~~
The LVM1 code got removed wholesale, and replaced with a much better
designed 'device mapper'.
- This is backwards compatable with the LVM1 disk format.
- Device mapper does require new tools to manage volumes however.
You can get these from ftp://ftp.sistina.com/pub/LVM2/tools/
Debugging options.
~~~~~~~~~~~~~~~~~~
During the stabilising period, it's likely that the debugging options
in the kernel hacking menu will trigger quite a few problems.
Please report any of these problems to [email protected]
rather than just disabling the relevant CONFIG_ options.
Merging of kksymoops means that the kernel will now spit out
automatically decoded oopses (no more feeding them to ksymoops).
For this reason, you should always enable the option in the
kernel hacking menu labelled "Load all symbols for debugging/kksymoops".
Compiler issues.
~~~~~~~~~~~~~~~~
- The recommended compiler (for x86) is still 2.95.3.
- When compiled with a modern gcc (Ie gcc 3.x), 2.5 will use additional
optimisations that 2.4 didn't. This may shake out compiler bugs that
2.4 didn't expose.
- Do not use gcc 3.0.x due to a stack pointer handling bug.
Security concerns.
~~~~~~~~~~~~~~~~~~
Several security issues solved in 2.4 are yet to be forward ported
to 2.5. For this reason 2.5.x kernels should not be tested on
untrusted systems. Testing known 2.4 exploits and reporting results
is useful.
Networking.
~~~~~~~~~~~
- ebtables
The bridging firewall code got merged. To manage these you'll need the ebtables
tool available from http://users.pandora.be/bart.de.schuymer/ebtables/
More on bridge-nf can be found at http://bridge.sourceforge.net
Ports.
~~~~~~
- 2.5 features support for several new architectures.
- x86-64 (AMD Hammer)
in-tree isn't up to date with ftp.x86-64.org
- ppc64
- UML (User mode Linux)
See http://user-mode-linux.sf.net for more information.
- uCLinux. 68k(w/o MMU) and v850 platforms.
- Several in-tree ports are lagging behind their out-of-tree variants.
TODO.
~~~~~
- Crypto
FIXME: userspace?
- IPSec
FIXME: userspace?
- IPv6
FIXME: userspace?
- Reiser4 ?
http://www.namesys.com/snapshots/2002.10.29/reiser4progs-0.1.0.tar.gz
- POSIX ACLs
FIXME: userspace?
- Provide more info other new filesystems..
- futexfs
- eventpollfs
- hugetlbfs
Need checking.
~~~~~~~~~~~~~~
- Someone reported evolution locks up when calender/tasks/contacts is selected.
http://lists.ximian.com/archives/public/evolution-hackers/2002-March/004292.html
reports this as an evolution/ORBit problem. Did it get fixed ?
--
| Dave Jones. http://www.codemonkey.org.uk
On Wed, 6 Nov 2002, Dave Jones wrote:
> PnP layer
> ~~~~~~~~~
> - Support for plug and play devices such as early ISAPnP cards has
> improved a lot in the 2.5 kernel. You should no longer need to
> futz with userspace tools to configure IRQ's and the likes.
> - This code is very young, and needs more work, but is more
> actively maintained than the previous ISAPnP work.
> - Report any regressions in plug & play functionality to
> Adam Belay <[email protected]>
Please, correct some mistakes:
- old ISA PnP code does not require user space tools, too
- the new code is mostly based on idea to make behaviour same as for PCI
devices (probe, remove etc. callbacks) and to merge the PnP BIOS
access code
- maintaince? the code was nearly complete, almost all device drivers were
converted to support ISA PnP (thus autoconfiguration which has moved to
the new PnP layer); I don't know what you mean that the code is more
actively maintained; it was maintained to satisfy my goals
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linux http://www.suse.com
Dave Jones <[email protected]> writes:
> Ports.
> ~~~~~~
> - 2.5 features support for several new architectures.
...
> - uCLinux. 68k(w/o MMU) and v850 platforms.
A nit, I suppose, but the v850 is not a `platform' in the conventional
sense of the term, it's a completely new architecture. uCLinux, OTOH,
is not an architecture, but a tweak to various parts of the kernel to
remove the requirement for an MMU (yeah I know what you meant, but
others may not).
Thanks,
-Miles
--
I have seen the enemy, and he is us. -- Pogo
> Need checking.
> ~~~~~~~~~~~~~~
> - Someone reported evolution locks up when calender/tasks/contacts is selected.
> http://lists.ximian.com/archives/public/evolution-hackers/2002-March/004292.html
> reports this as an evolution/ORBit problem. Did it get fixed ?
No. DaveM had a copy of some bits about it and pointed Alexeywards,
nothing more heard since.
On Wed, Nov 06, 2002 at 03:37:10PM +0100, Jaroslav Kysela wrote:
> - old ISA PnP code does not require user space tools, too
> - the new code is mostly based on idea to make behaviour same as for PCI
> devices (probe, remove etc. callbacks) and to merge the PnP BIOS
> access code
> - maintaince? the code was nearly complete, almost all device drivers were
> converted to support ISA PnP (thus autoconfiguration which has moved to
> the new PnP layer); I don't know what you mean that the code is more
> actively maintained; it was maintained to satisfy my goals
Ok, I'll make those changes. My apologies for casting the previous
work in such a bad light 8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Wed, 2002-11-06 at 15:08, Dave Jones wrote:
> Need checking.
> ~~~~~~~~~~~~~~
> - Someone reported evolution locks up when calender/tasks/contacts is selected.
> http://lists.ximian.com/archives/public/evolution-hackers/2002-March/004292.html
> reports this as an evolution/ORBit problem. Did it get fixed ?
I found this in Michael Meeks activitylog
(http://www.gnome.org/~michael/activity.html):
2002-10-31: It looks like Ronald Kuetemeier located the problem with
ORBit-0.5 causing problems for evolution on the 2.5 kernel series, a
change in getpeername behavior - good man.
This is what I found:
thread:
http://lists.ximian.com/archives/public/evolution-hackers/2002-October/005193.html
patch to orbit:
http://lists.ximian.com/archives/public/evolution-hackers/2002-October/005218.html
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
On Wed, 2002-11-06 at 09:08, Dave Jones wrote:
Hey Dave, good job!
One idea: how about covering new system calls? We have the thread calls
Ingo did, the sched_[set|get]affinity calls, AIO, etc.
Couple points...
> Kernel preemption.
> ~~~~~~~~~~~~~~~~~~
> - The much talked about preemption patches made it into 2.5.
> With this included you should notice much lower latencies especially
> in demanding multimedia applications.
> - Note, there are still cases where preemption must be temporarily disabled
> where we do not. If you get "xxx exited with preempt count=n" messages
> in syslog, don't panic, these are non fatal, but are somewhat unclean.
> - Report such cases (and any other preemption related problems) to
> [email protected]
I just want to clarify that, in the second point, the "xxx exited with
preempt_count=n" message and not disabling preemption are two different
issues.
The "xxx exited" message is a general debugging notice that a lock was
not dropped. Relevant to the whole system (regardless of preemption,
possibly) but a real problem for preemption because the lock count is
off.
Not disabling preemption where needed is like an SMP race condition.
There may be a some per-CPU data left that needs explicit protection but
hopefully not much.
Finally, if you DO notice high latency with kernel preemption enabled in
a specific code path, please report that to Andrew Morton
<[email protected]> and myself <[email protected]>. We consider those bugs.
The report should be something like "the latency in my xyz application
hits xxx ms when I do foo but is normally yyy" where foo is an action
like "unlink a huge directory tree".
> procps
> ~~~~~~
> - The 2.5 /proc filesystems changed some statistics, which confuse
> older versions of procps. Rik van Riel and Robert Love have
> been maintaining a version of procps during the 2.5 cycle which
> tracks changes to /proc which you can find at http://tech9.net/rml/procps/
> - Alternatively, the original procps by Albert Cahalan now supports
> the altered formats since v3.0.5, but lags behind the bleeding edge
> version maintained by Rik and Robert. -- http://procps.sf.net/
> - The /proc/meminfo format changed slightly which also broke
> gtop in strange ways.
Just a note that the tree Rik and I are hacking on is the original and
not a fork. It is the same tree mkj created and is in the official Red
Hat CVS repository. It just has not had much activity lately and now it
has new blood :)
Albert's tree is a fork.
If you are using the official procps package, I think you need at least
2.0.8 or so - but the latest version is ideal, which is 2.0.10.
> Debugging options.
> ~~~~~~~~~~~~~~~~~~
> During the stabilising period, it's likely that the debugging options
> in the kernel hacking menu will trigger quite a few problems.
> Please report any of these problems to [email protected]
> rather than just disabling the relevant CONFIG_ options.
>
> Merging of kksymoops means that the kernel will now spit out
> automatically decoded oopses (no more feeding them to ksymoops).
> For this reason, you should always enable the option in the
> kernel hacking menu labelled "Load all symbols for debugging/kksymoops".
Please please please test with CONFIG_PREEMPT, CONFIG_DEBUG, and
CONFIG_KKALLSYMS enabled. Kernel preemption gives us the ability to do
a whole slew of debugging checks like sleeping with locks held,
scheduling while atomic, exiting with locks held, etc. etc.
> Need checking.
> ~~~~~~~~~~~~~~
> - Someone reported evolution locks up when calender/tasks/contacts is selected.
> http://lists.ximian.com/archives/public/evolution-hackers/2002-March/004292.html
> reports this as an evolution/ORBit problem. Did it get fixed ?
Not yet. I have talked to the Evolution/ORBit guys about this -
especially Elliot Lee.
It is an ORBit problem and is currently not fixed as of the latest
release. The problem is 2.4, actually, which has bad behavior with
getpeername() - it does not fill in the sun_path member. ORBit works
around this behavior, which breaks 2.5 which does fill in the value.
A quick fix is to just have ORBit set sun_path to null after calling
getpeername().
Robert Love
On Wed, Nov 06, 2002 at 11:18:01AM -0500, Robert Love wrote:
> One idea: how about covering new system calls? We have the thread calls
> Ingo did, the sched_[set|get]affinity calls, AIO, etc.
I've toyed with this idea, but wondered if perhaps a seperate
document would be a better idea. Ie, keep this one as a
end-users guide, and have a seperate programmers guide
covering things like API changes and the likes.
The latter would likely be more time consuming than the former,
we'll see how things go..
> > - Note, there are still cases where preemption must be temporarily disabled
> > where we do not. If you get "xxx exited with preempt count=n" messages
> > in syslog, don't panic, these are non fatal, but are somewhat unclean.
> I just want to clarify that, in the second point, the "xxx exited with
> preempt_count=n" message and not disabling preemption are two different
> issues.
Good point, that was confusing. Cleaned up.
> Not disabling preemption where needed is like an SMP race condition.
> There may be a some per-CPU data left that needs explicit protection but
> hopefully not much.
Wasn't there also some issue in various drivers ? I believe Alan cited
the 8390 net driver as one example.
> Just a note that the tree Rik and I are hacking on is the original and
> not a fork. It is the same tree mkj created and is in the official Red
> Hat CVS repository. It just has not had much activity lately and now it
> has new blood :)
>
> Albert's tree is a fork.
*sigh* politics. I changed that text after Albert mailed me complaining
about the original. Something tells me I'm not going to be able to
please both of you. I'll mangle it again, and see which one of you
complains next time 8-)
All other suggestions added/changed/etc.
Thanks for the feedback
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On 6 Nov 2002, Miles Bader wrote:
> Dave Jones <[email protected]> writes:
> > Ports.
> > ~~~~~~
> > - 2.5 features support for several new architectures.
> ...
> > - uCLinux. 68k(w/o MMU) and v850 platforms.
>
> A nit, I suppose, but the v850 is not a `platform' in the conventional
> sense of the term, it's a completely new architecture. uCLinux, OTOH,
> is not an architecture, but a tweak to various parts of the kernel to
> remove the requirement for an MMU (yeah I know what you meant, but
> others may not).
Yep, and since there are (unfinished) ports to MMU-less variants of machines
that are already supported by normal Linux, some more uClinux support may
appear in `normal' arch subdirectories in the future.
E.g. MMU-less Atari and Amiga (and Mac, anyone working on that?) are better off
with the platform support in arch/m68k/ than the one in arch/m68knommu/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Nov 06, 2002 at 03:37:10PM +0100, Jaroslav Kysela wrote:
> On Wed, 6 Nov 2002, Dave Jones wrote:
>
> > PnP layer
> > ~~~~~~~~~
> > - Support for plug and play devices such as early ISAPnP cards has
> > improved a lot in the 2.5 kernel. You should no longer need to
> > futz with userspace tools to configure IRQ's and the likes.
> > - This code is very young, and needs more work, but is more
> > actively maintained than the previous ISAPnP work.
> > - Report any regressions in plug & play functionality to
> > Adam Belay <[email protected]>
>
> Please, correct some mistakes:
>
> - old ISA PnP code does not require user space tools, too
> - the new code is mostly based on idea to make behaviour same as for PCI
> devices (probe, remove etc. callbacks) and to merge the PnP BIOS
> access code
> - maintaince? the code was nearly complete, almost all device drivers were
> converted to support ISA PnP (thus autoconfiguration which has moved to
> the new PnP layer); I don't know what you mean that the code is more
> actively maintained; it was maintained to satisfy my goals
>
> Jaroslav
I agree with Jaroslav's statements. The PnP Layer Rewrite does not modify
much ISA PnP code. It does, however, make substantial improvements to the
PnP BIOS code. This protocol required user level tools to change resource
configurations prior to my work. The PnP BIOS is used to detect non-isa
system devices, such as serial ports.
The reason ISA PnP drivers have to be modified is primarily that the PnP
Layer integrates PnP protocols into the driver model. Before this drivers
would call the protocols individually. Each protocol would have unique
functions to activate and disable devices. Actually this is not entirely
true becuase pnp bios was not used at all in earlier 2.5 kernels. Any way,
one of the major benifits of the PnP Layer is that it offers an expandible
PnP interface that is not dependent on PnP Protocol. This will make it
easier to intigrate new PnP protocols such as ACPI.
In conclusion, the PnP Layer work is independent of ISAPNP and acts as a
unified interface for all plug and play devices. PnP BIOS improvements
were made in order to fully support the PnP Layers capabilities.
I am primarily maintaining the PnP Layer and the PnP BIOS protocol. I
will also be converting old ISAPnP drivers and supporting ISAPnP as needed.
Please all mainainers with PnP drivers or drivers with PnP capable devices
convert your drivers to the new PnP Layer.
Thanks for maintaining this feature list.
-Adam
P.S.: Many drivers have been converted already. I'm working on the ALSA
sound blaster driver now and I have made a patch for the gamemport driver
that I will be releasing soon.
On Wed, 2002-11-06 at 11:53, Dave Jones wrote:
> I've toyed with this idea, but wondered if perhaps a seperate
> document would be a better idea. Ie, keep this one as a
> end-users guide, and have a seperate programmers guide
> covering things like API changes and the likes.
> The latter would likely be more time consuming than the former,
> we'll see how things go..
Good idea :)
> Wasn't there also some issue in various drivers ? I believe Alan cited
> the 8390 net driver as one example.
Yes, its mainly a performance problem. In the 8390, for example, you
can get preempted with the specific interrupt disabled (from
disable_irq()).
I will get to fixing those... but biggest concern is the remaining
unprotected per-CPU data. Which, thankfully, is looking really good -
we are stable.
> > Albert's tree is a fork.
>
> *sigh* politics. I changed that text after Albert mailed me complaining
> about the original. Something tells me I'm not going to be able to
> please both of you. I'll mangle it again, and see which one of you
> complains next time 8-)
Sigh, I guess. The politics should be whose tree is better - there
should be no issue that Michael Johnson's tree is the original.
> All other suggestions added/changed/etc.
>
> Thanks for the feedback
You are welcome.
Robert Love
In article <[email protected]>,
Adam Belay <[email protected]> wrote:
|
| P.S.: Many drivers have been converted already. I'm working on the ALSA
| sound blaster driver now and I have made a patch for the gamemport driver
| that I will be releasing soon.
Thank you, that sure helps me understand that problem.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On 6 Nov 2002, Robert Love wrote:
> > procps
> > ~~~~~~
> > - The 2.5 /proc filesystems changed some statistics, which confuse
> > older versions of procps. Rik van Riel and Robert Love have
> > been maintaining a version of procps during the 2.5 cycle which
> > tracks changes to /proc which you can find at http://tech9.net/rml/procps/
> > - Alternatively, the original procps by Albert Cahalan now supports
> > the altered formats since v3.0.5, but lags behind the bleeding edge
> > version maintained by Rik and Robert. -- http://procps.sf.net/
> > - The /proc/meminfo format changed slightly which also broke
> > gtop in strange ways.
>
> Just a note that the tree Rik and I are hacking on is the original and
> not a fork. It is the same tree mkj created and is in the official Red
> Hat CVS repository. It just has not had much activity lately and now it
> has new blood :)
>
> Albert's tree is a fork.
>
> If you are using the official procps package, I think you need at least
> 2.0.8 or so - but the latest version is ideal, which is 2.0.10.
I don't want to get into politics on this, but wasn't Albert the
maintainer of procps? I think I saw him state that you guys started
releasing your own versions instead of sending him patches,
I can't find a maintainer's name in any of the not so old versions I
have here, so I am just replaying my recollection of his statement as a
question.
For what it's worth, both recent versions seem to work, his top is far
prettier;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thu, 2002-11-07 at 11:33, Bill Davidsen wrote:
> I don't want to get into politics on this, but wasn't Albert the
> maintainer of procps? I think I saw him state that you guys started
> releasing your own versions instead of sending him patches,
I want to avoid the politics, but real quick...
Michael K. Johnson (yes, that mkj) wrote the current procps package
sometime ago. With version 2.0.7, development pretty much stopped.
Albert had patches for procps that were not being accepted, so he forked
and put a new tree on SourceForge to continue development. This is a
good thing, and I do not fault him for it. But none-the-less it is a
fork.
Rik and I came along, get CVS access to the original tree at Red Hat,
and started development of that. This tree is what most distributors
include. So Rik and I are currently maintaining mkj's official tree.
Other than that, I do not care. Use Albert's tree or ours. All I care
about is having someone not post to every procps-related email "your
package sucks, use 3.0".
Robert Love