the first cool action they placed on the market was to substitute all occurrences of LMC in the driver by SBE and make some other incompatible changes to make sure that the old tools wouldn't work with the "new" driver and vice versa. Surprisingly the kernel maintainers did not like this very much so the drivers in the latest kernels are somewhat old and conflicting with the "real" drivers.

What's more, their driver version 3.2 doesn't compile with 2.4.21 and up, so unless they've eventually released their highquality patch/driver/tool/utilities/extras + telnet and more bundle in version 4.0 version which will probably only work up to 2.4.24 anyway (due to the latest HDLC changes), one has to stick to an old version of the driver, which works somewhat but given the extraordinary code quality I would be very surprised if that's a synonym for a nice uptime.

There's something about WAN card manufacturers that seems to say: If you hate us for the sad driver quality, check back with our competition and then come back later...

In 2.6.4-rc1-mm2, there's exactly one entry marked "Unmaintained" (PCMCIA SUBSYSTEM) and there are very few marked "Orphan".

I don't have a strong opinion on this, but my impresion was that usually unmaintained device drivers are not listed in MAINTAINERS.

I've released the 021 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz

(Yes, there was no 020 release announcement, that tarball had a number of build issues that prevented rpms from being generated, hence the need for a 021 release. A certain new Ximian/SuSE/Novell employee owes me some beer now that he broke the build and I had to fix it...)

rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.src.rpm

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

I think udev is pretty much mature now. The TODO list is pretty much empty, and I've integrated in all of the assorted patches that the different distros were using. If there's anything missing from udev, or any patches that I've missed, please let me and the people at the linux-hotplug-devel mailing list know about it.

Major changes from the 019 version:

• new variable $local for the udev.permission file allows permissions to be set for the currently logged in user.
• new binary, udevstart, to help out people with distros that needed the udev_start program to have a few /dev entries be created before it could run.
• new udevinfo functionality (can handle the symlinks correctly now.)
• number of other small fixes.

Thanks to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

Two other things about this release that Kay just reminded me about:

• if you have been using the tarballs, please delete /sbin/udevinfo by hand, as it is now placed in /usr/bin/udevinfo. Users who use the rpm or some other kind of package system will have no problems with this.
• the old style %2c format has now been removed in favor of the %c{2} style. Any old udev.rules files will need to be converted (you had a few releases to do this...)

And another one I just remembered:

• we now support multiple symlink rules. They aren't really documented well, but hopefully the author of that patch will fix this soon...

It's even worse. The user logged into the lowest-numbered console will get owner of the newly created file when using $local.

So if I log into tty2 and plug in my USB stick I will be owner of /dev/sda1. If another guy comes along, logs into tty1, unplugs my USB stick and replugs it, he'll be owner of /dev/sda1. But if I log out now, re-login on tty2 and replug the stick again, I won't get the owner of /dev/sda1 but the other guy again. This will certainly break things - at least on Fedora Core 1. Maybe it's different with other distributions/glibc/utmp variants/versions.

Ick, well you are describing a pretty pathalogical situation. I suspect for 99.9% of the users who would use this option, it will work just fine, as they only have 1 user on the system at a time.

So, if you have multiple users on the physical system, then don't use $local :)

Feel free to send a update to the documentation that illustrates this limitation of the feature.

the kernel is changing models from one which automatically loaded modules when userspace tried to access the device, to one where the proper modules are loaded when the hardware is found.

Note that this is a much more sane model due to removable devices, and instances of multiple types of the same kind of devices in the same system.

So no, udev is not going to handle this "issue" except in the case of removable devices and their partitions. Which is already working in udev today.

OPENIB.ORG INFINIBAND DRIVERS RELEASE -- 2004-03-05

We are proud to announce the initial availability of the OpenIB.org InfiniBand stack. This is a fully open source (See the section on SDP intellectual property for some important information, though.) InfiniBand stack that includes a low-level driver for Mellanox HCA hardware, a midlayer, and a number of useful upper-layer protocols including IP-over-InfiniBand, SCSI RDMA Protocol, Sockets Direct Protocol, uDAPL and MPI. In addition userspace utilities are available, including the OpenSM subnet manager.

An initial drop of this source is available from <http://openib.org>. Additional protocols and further enhancements will be added in upcoming releases. In the next few days, we will also be bringing up mailing lists, source code control, and so on.

We look forward to working with the entire Linux community to continue to develop these drivers.

TODO

We are fully aware that our code is far from being acceptable for inclusion in the Linux kernel, and we are very committed to doing the hard work required to clean up the source. We believe that in addition to the benefits of being in the standard kernel, we will find huge improvements in the quality, performance and robustness of our drivers.

As a starting point, here is a list of some of the tasks we believe must be completed before these drivers can be seriously considered for inclusion in the kernel. We would welcome any suggestions of tasks that we have forgotten. Of course patches would be even better!

• Use a more standard naming convention (tTS_IB_TYPE_NAME -> ib_type_name, tsIbFunctionName -> ib_function_name, etc)
• Get rid of bizarro types such as tUINT32 -- replace with Linux standard u32 etc.
• Run source through scripts/Lindent (and then fix by hand, since lots of things will no longer line up)
• Get rid of XXX_exports.c files and move EXPORT_SYMBOL next to definition in source.
• Change MODULE_PARM -> module_param
• Use DMA mapping API so we work properly with non-coherent caches, IOMMUs etc. Add a function to get struct device * for an IB device so ULPs can call sync functions (embed struct device in struct ib_device?). (How do we handle systems with limited DMA mapping capacity?)
• Fix up ioctls, userspace interface so that 32-bit userspace works with a 64-bit kernel.
• Get rid of ib_poll module; move all timers to standard Linux timers (CM can use a work queue plus schedule_delayed_work).
• Get rid of ib_services module (move TS_TRACE etc. to dev_printk)
• Add missing pieces of API for currently unused IB features: deal with RD (EECs, etc -- including CM support), verbs extensions.
• Get rid of IPoIB address hash and just use native 20-byte addresses (keep 6-byte hash as an option for compatibility with existing applications?)
• Rewrite client query support (SA and DM) to be more extensible, simpler, deal with component mask.
• Add sysfs support.

• In Mellanox HCA driver, clean up mosal. Some obvious targets (there's lots more though):

  • Grunging through kernel code to find the mlock/munlock pointers especially has to go (mosal_mlock.c). We need to get VM experts from LKML to tell us how to handle memory translation and locking.
  • Turn MT_KERNEL back to __KERNEL__
  • Use native spinlocks.
  • Turn driver into a real PCI driver (rather than reimplementing a worse version of PCI bus scan).

SDP intellectual property

Microsoft believes that they own certain intellectual property relating to the Sockets Direct Protocol (SDP). Therefore, we are including the following disclaimer required by Microsoft's license in SDP source that relates to the implementation of the protocol:

"This source code may incorporate intellectual property owned by Microsoft Corporation. Our provision of this source code does not include any licenses or any other rights to you under any Microsoft intellectual property. If you would like a license from Microsoft (e.g., to rebrand, redistribute), you need to contact Microsoft directly."

We realize that this is incompatible with open source licensing, and we are working to find a more satisfactory solution, but for the time being we are forced to comply with Microsoft's license.

Please make sure you have fully understood the implications of Microsoft's claims before you redistribute any of the SDP source that contains the above disclaimer.

Several people have requested that we split the possibly-encumbered SDP code into a separate package so that they don't have to download it to get the free code. To allow that, I have split the kernel code into two packages:

infiniband-kernel-2004-03-05.tar.bz2
infiniband-kernel-sdp-2004-03-05.tar.bz2

If you wish to build SDP, you will need to download both packages and move the SDP files into the appropriate place in the tree. For all other protocols, only the first package (containing only pure dual GPL/BSD code) is required.

The new snapshot is available now from <http://openib.org/downloads>. (It also contains a few fixes and code cleanups as compared to the 2004-02-26 drop)

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4-rc2/2.6.4-rc2-mm1/

• Added Jens's patch which teaches the kernel to use DMA when reading audio from IDE CDROM drives. These devices tend to be flakey, and we need lots of testing please.
• Re-added the device mapper update

• Brought back Ingo's patch which permits remap_file_pages() to set the memory access permissions on a per-page basis. This is mainly interesting for its very significant performance benefits to UML.

  Breaks the build on most architectures. There are how-to-fix-it instructions in the changelog.

• A new version of the patch which permits ext3 quota updates to be fully journalled.

I've started collecting various data (including oprofile) using our DBT-2 (OLTP) workload with lvm2 on linux 2.6.2 and 2.6.3 on ia32 and ia64 platforms:

http://developer.osdl.org/markw/lvm2/

So far I've only varied the stripe width with lvm, from 8 KB to 512 KB, for PostgreSQL that is using 8 KB sized blocks with ext2. It appears that a stripe width of 16 KB through 128KB on the ia64 system gives the best throughput for the DBT-2 workload on a volume that should be doing mostly sequential writes.

I'm going to run through more tests varying the block size that PostgreSQL uses, but I wanted to share what I had so far in case there were other suggestions or recommendations.

Here's one thought: look at the i/o rates on individual drives using each stripe size. You *might* see that one size does far fewer seeks than others, which is a secondary thing to optimize after throughput IMHO.

If you don't have a tool for this I can send you the latest diorate which does stuff like this, io rate perdrive or per partition, something I occasionally find revealing.

I am pleased to announce the launch of an open source development project for the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been created and is hosted at http://ipw2100.sf.net.

The driver, as it currently stands, is able to associate and communicate in Infrastructure mode. Support for both 2.4 and 2.6 is available. We are releasing this driver now as "early beta" code to get feedback and help in the development, so expect bugs (and please report them)! Of course Intel will continue the effort (as part of this Open Source project). We are planning to add support of all key wireless features (adhoc, WEP, etc) over the next few months, quicker with help from others in the community.

NOTE: Let me reiterate -- this driver is in active development. Features and capabilities available on other operating systems have not all been implemented at this time. This includes wireless features (adhoc, wep) as well as performance and power savings.

I look forward to working with the community to improve and enhance the driver.

So if you have an Intel wireless 802.11b miniPCI network adapter in your laptop... download the bits, give it a whirl, and let me know how it goes. Please also let us know if you encounter any problems that may be related to specific distributions.

I took a look at the website and see the GPL driver and the closed firmware.

Is it really *firmware*, in that it loads and executes purely within the Intel PRO/Wireless 2100 itself and not in the linux kernel on the main CPU? If so, bravo!

Does a similar effort exist for the upcoming Sonoma 802.11a/b/g component? Will Linux support be available for Sonoma at launch?

I used the patch to compile two identical kernels with gcc 3.3.3 and icc 8.0 with oprofile support built in.

The optimization switches were chosen quite conservative, i.e. "-O2 -Ob1", no IPO, and of course: no MMX, SSE, and SSE2 stuff inside the kernel (thus disabling Intel's great vectorizer).

Profiling: lmbench ran ten times but time measurements were taken from oprofile (on Pentium 4, GLOBAL_POWER_EVENTS in kernel space only, counter overflow: 3.000).

Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.

Thus, take the kernel patch as a good basis for modifying the compiler switches and other things to get more performance gains. As I know, a lot of people are looking for a patch.

Please check the patch file; you have to modify a lot of things in 2.6.3 to create a quite stable working version of the kernel. The patch is not just about changing some minor Makefile things...

Here's a first cut at killing global plugging of block devices to reduce the nasty contention blk_plug_lock caused. This introduceds per-queue plugging, controlled by the backing_dev_info. Observations:

• Most uses of blk_run_queues() without a specific context was bogus. Usually the act of kicking the targets in question should be (and already are) performed by other activities, such as making the vm flushing run to free memory.
• Some use of blk_run_queues() really just want to kick the final queue where the bio goes to. I've added bio_sync() (BIO_RW_SYNC) to manage those, if the queue needs unplugging we'll do it when holding the lock for the queue already.
• The dm bit needs careful examination and checking of Joe. It could be more clever and maintain plug state of each target, I just added a dm_table unplug all functionality.

Patch is against 2.6.4-rc2-mm1.

A few small fixes since -rc3, most notably an OHCI bug that would corrupt memory and seems to have been the reason for the "Bad page flags" bug at least on ppc64 (it's not been reported on x86, as far as I know, but I don't see why the corruption couldn't have happened there too).

The full changelog from 2.6.3 is on the ftp-sites along with the patches and tar-balls, and the BK trees have been updated.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/2.6.4-mm1/

• The CPU scheduler changes in -mm (sched-domains) have been hanging about for too long. I had been hoping that the people who care about SMT and NUMA performance would have some results by now but all seems to be silent.

  I do not wish to merge these up until the big-iron guys can say that they suit their requirements, with a reasonable expectation that we will not need to churn this code later in the 2.6 series.

  So. If you have been testing, please speak up. If you have not been testing, please do so.

• Major surgery against the pagecache, radix-tree and writeback code. This work is to address the O_DIRECT-vs-buffered data exposure horrors which we've been struggling with for months.

  As a side-effect, 32 bytes are saved from struct inode and eight bytes are removed from struct page.

  This change will break any arch code which is using page->list and will also break any arch code which is using page->lru of memory which was obtained from slab.

  It seems to work OK here, but I suggest people not rush out and convert all of the corporate finance department's servers to 2.6.4-mm1.

  The basic problem which we (mainly Daniel McNeil) have been struggling with is in getting a really reliable fsync() across the page lists while other processes are performing writeback against the same file. It's like juggling four bars of wet soap with your eyes shut while someone is whacking you with a baseball bat. Daniel pretty much has the problem plugged but I suspect that's just because we don't have testcases to trigger the remaining problems. The complexity and additional locking which those patches add is worrisome.

  So the approach taken here is to remove the page lists altogether and replace the list-based writeback and wait operations with in-order radix-tree walks.

  The radix-tree code has been enhanced to support "tagging" of pages, for later searches for pages which have a particular tag set. This means that we can ask the radix tree code "find me the next 16 dirty pages starting at pagecache index N" and it will do that in O(log64(N)) time.

  This affects I/O scheduling potentially quite significantly. It is no longer the case that the kernel will submit pages for I/O in the order in which the application dirtied them. We instead submit them in file-offset order all the time.

  This is likely to be advantageous when applications are seeking all over a large file randomly writing small amounts of data. I haven't performed much benchmarking, but tiobench random write throughput seems to be increased by 30%. Other tests appear to be unaltered. dbench may have got 10-20% quicker, but it's variable.

  There is one large file which everyone seeks all over randomly writing small amounts of data: the blockdev mapping which caches filesystem metadata. The kernel's IO submission patterns for this are now ideal.

  Because writeback and wait-for-writeback use a tree walk instead of a list walk they are no longer livelockable. This probably means that we no longer need to hold i_sem across O_SYNC writes and perhaps fsync() and fdatasync(). This may be beneficial for databases: multiple processes writing and syncing different parts of the same file at the same time can now all submit and wait upon writes to just their own little bit of the file, so we can get a lot more data into the queues.

  It is trivial to implement a part-file-fdatasync() as well, so applications can say "sync the file from byte N to byte M", and multiple applications can do this concurrently. This is easy for ext2 filesystems, but probably needs lots of work for data-journalled filesystems and XFS and it probably doesn't offer much benefit over an i_semless O_SYNC write.

• Dropped the hotplug CPU patches: bits of them were merged into Linus's kernel and things broke.
• Various little fixes as usual.

Below is a patch against 2.6.4 that provides a low-overhead system-call auditing framework for Linux that is usable by LSM components (e.g., SELinux). This is an update of the patch discussed in this thread:
http://marc.theaimsgroup.com/?t=107815888100001&r=1&w=2

In brief, it provides for netlink-based logging of audit records that have been generated in other parts of the kernel (e.g., SELinux) as well as the ability to audit system calls, either independently (using simple filtering) or as a compliment to the audit record that another part of the kernel generated.

The main goals were to provide system call auditing with 1) as low overhead as possible, and 2) without duplicating functionality that is already provided by SELinux (and/or other security infrastructures). This framework will work "stand-alone", but is not designed to provide, e.g., CAPP functionality without another security component in place.

This updated patch includes changes from feedback I have received, including the ability to compile without CONFIG_NET (and better use of tabs, so use -w if you diff against the older patch).

Please see http://people.redhat.com/faith/audit/ for an early example user-space client (auditd-0.4.tar.gz) and instructions on how to try it.

My future intentions at the kernel level include improving filtering (e.g., syscall personality/exit codes) and syscall support for more architectures. First, though, I'm going to work on documentation, a (real) audit daemon, and patches for other user-space tools so that people can play with the framework and understand how it can be used with and without SELinux.

I've just packaged up the latest Linux hotplug scripts into a release, which can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.gz or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.bz2

This is a snapshot of the recent development in the scripts, and should be used by anyone who has reported a bug or sent me a patch against the last release, to check if your fix is in or not.

If I have missed any changes, please let me know and send the patch to me and the linux-hotplug-devel mailing list. I'll collect them all and make a "official" release afterwards.

Sorry for delaying so long since the last hotplug release.

This patch updates UML to 2.6.4. Besides the update, there were the following changes since the last patch:

• a bug which caused either a crash in the kernel or a BUG at exit.c:793 was fixed
• a bug which caused a crash when a process tried to dump core was fixed
• the hang early in boot on GHz hosts is gone
• various other

The 2.6.4-1 UML patch is available at
http://www.user-mode-linux.org/mirror/uml-patch-2.6.4-1.bz2

BK users can pull my 2.5 repository from
http://www.user-mode-linux.org:5000/uml-2.5

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

I am proud to announce the official launch of the Umbrella security project for Linux on handheld devices.

Umbrella implements a combination of process based mandatory access control and authentication of files. Umbrella relies on the efford of developers, in order to implement a secure system. It is our philosophy that it is not possible to make a secure Linux system without involving the developers of the various applications used on the system!

The design of Umbrella is aimed to be very simple for developers to use and understand. It is not possible to make an ambiguous security configuration for Umbrella - unlike more complex security mechanisms like e.g. Security-Enhanced Linux.

You may find more details below and on our web site:
http://umbrella.sourceforge.net

-- UMBRELLA INTRODUCTION --

In designing Umbrella for handheld devices, there are several criteria that differ from that of regular computer systems. The most important are the available resources and the fact that heavy change in software do not occur. Furthermore the PDA, used for test purposes in this project, is not a development tool only a computer intended to do specific tasks such as organizer, email, games, communication etc.

Though resources on handhelds are limited, the devices has become increasingly more powerful and able to run a wide range of programs from different vendors. Umbrella is designed, such that software can be executed in a secure manner and thereby protecting the system against malicious code and viruses.

The overall structure of Umbrella is a mandatory access control scheme for running processes together with an authentication of files and run time integrity checking of the executables.

-- PROCESS BASED MAC --

The idea of processes based mandatory access control is strongly supported by the tree structure for processes in Linux.

Umbrella gives every process in Linux a set of restrictions. The rule is that every process must be at least as restricted as it parent. In practice, this works as inheritance: When forking a new process, it immediately gets the restrictions of it's parent, and if the parent have specified more restrictions for it's child(ren) then the "child restrictions" and the restrictions of the parent are combined (a union of the two sets of restrictions).

-- WHAT IS RESTRICTIONS? --

A restriction is just a string, e.g. "/etc". These strings can represent a path in the file system e.g. "/etc/passwd" or "/etc" or the restriction can represent a special ability e.g. "net" or "fork".

A path restriction restricts the process from the specified directory and everything below it. If the path-restriction is a file, nothing below exists, and the process is thus restricted from that single file only.

Ability restrictions is used to restrict from special operations, that cannot be restricted through files. An example of this is the network, which is only handled through the kernel. The restrictions for the network, the ability to fork new processes and others is handled within Umbrella.

It will be very easy to add new path restrictions to the system, as the way they are handled within the kernel are the same. From a user/programmer point of view, the interface will be made very simple (not implemented yet). Adding more ability restrictions require small modifications of the Umbrella code (hook implementations). At first we aim to implement the general, but simple, ability restrictions (like net and fork). However it is fairly easy to extend these to implement more fine grained restrictions.

Umbrella-0.2 can be downloaded from:
http://prdownloads.sourceforge.net/umbrella/umbrella-0.2.tar.bz2?download

The tarball includes detailed instructions for how to try out Umbrella.

I've released the 022 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022.tar.gz

rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.src.rpm

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

There are a few minor bugfixes in this release, and a few new features. Which pretty much seems to prove my "udev is mature" statement I made for the last release :)

Oh, I'd like to thank OSDL for doing some preliminary speed tests (as well as functionality tests) on udev. Unofficially it looks like it only took 7 seconds extra to use udev to name 1000 scsi disks (and the rule was calling out to scsi_id for every disk, and then parsing over 1000 rules.) Note that is 7 seconds extra to name _all_ of the disks at once using the scsi_debug module. That's not too shabby at all.

Where are those "hotplug is too slow to do device naming" whiners now...

Major changes from the 021 version:

• lots of security audits in libsysfs and the remaining udev files.
• fixes for the foo-%c{N} type rules
• add foo-%c{N+} type rule option (see the manpage for info).
• allow node permissions to be specified in the rules file.
• more tests added to the test scripts
• number of other small fixes.

Again a big thanks to Kay Sievers for sending me patches faster than I can integrate them. udev is a viable program due to his excellent work.

Thanks also to everyone else who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

Here goes the third pre release of 2.4.26.

It contains a bunch of NFS client fixes, IA64/32-bit PPC updates, sisfb update, amongst others.

...so here comes 0.0.1! i have changed the device manager id to 3 because of Kevin Corry suggested this and also added more pci-ids. you can override the id scan be setting "biosraid.ignore_pci_ids" to "1". but you still need the proper raid signatures on your disks to get a raid volume.

basic read/write tests on a fat partition worked fine, but i cannot do more right now. the fan of my graphiccard is broken and i replaced the cooler with cpu heatsink and attached it with a string to the board. looks pretty crude!

Changelog:

• use new list API
• migrate to evms 2.3.0
• support for HPT 370, 370A, 302, 371, 375, 372N chipsets
• remove disk if it cannot be added the discover() output_list
• make all global variables static
• add boolean "biosraid.ignore_pci_ids" config option to optionally ignore the pci vendor and device ids of the ide controllers
• changed EVMS_DEVICE_MANAGER ID to 3

TODOs:

• access to the last sector (kernel 2.6 only)
• add mode raid levels
• create "whole disk" volume (currently only under .nodes)
• use sysfs for scanning
• more modular design to make it easier to add code for other controllers
• more testing

the next thing that i want to do is to implement the "whole disk" volume. it might be handy to have such a device for the grub bootloader and stuff. this also is a start for the last sector problem fix. the problem is that i should protect the sector #9 which contains the volume configuration. i do not think that it is possible to only write protect that sector but this would be a nice thing to do. the patch that applies against evms 2.3.0 is attached...

Just wanting clarification; what are we thinking about the future of suspend implementations? Let me throw my current understanding/suggestion in for starters:

• Drop PM_DISK?
• Apply patches making swsusp into suspend2, leaving out freezer changes until people are convinced the current solution is insufficient.
• Pavel keeps maintaining the end result? (I'm happy to maintain it if he wants; I'm assuming when I say this he'll still be dealing with S3 and Patrick will be deal with PM support proper).

Here's the current set of patches I've merged from various poeple..

Merging from Andrew, but also i2c updates, ALSA CVS merge, netconsole, prism54 driver merge, sata updates, carmel driver, pcmcia and nfs client updates..

And a few architectures updated: ia64, ppc32, sparc32, arm.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc1/2.6.5-rc1-mm1/

• A small update, mainly trying to get things stabilised after some problems with the disk unplugging and early x86 boot code. We may still have a problem with the latter.
• A PNP subsystem update

Here goes the fourth -pre of 2.4.26.

Pretty small (great!), containing a few network updates, SPARC64 fixes, Bluetooth fixes, IDE update (fixes for AMD chipset driver and inclusion of Medley software RAID driver by Thomas Horsten), amongst others.