Kernel Traffic #259 For 22 May 2004

Ah, I had seen that, but it doesn't seem to be very appropriate for an LCD controller in an embedded environment. TFT and STN (STN in particular) displays don't often fit into any of the standard mode definitions. There's also several settings which aren't in the DB, such as pixel clock polarity, dual vs. single panel STN etc.

I quite often get asked to make some arbitrary panel which a customer picked up somewhere dirt cheap to work, it is very useful to be able to give each of the parameters explicitly, even if they do not correspond to a mode listed in the DB.

I could make the code use the same XRESxYRES-DEPTH syntax though since the 2.4 version did (by copying the parsing code from fb_find_mode()), I just changed it to match i810fb for the 2.6 port.

I had considered extending the modedb stuff to support the requirements of embedded LCD controller drivers and to encompass a db of LCD panels by part number (Kconfig selectable, something like the NLS support perhaps) containing the extra options that you can have -- but I wasn't sure if it was something that would be useful only to me or to all embedded LCD driver authors.

The way to handle different types of displays, LCD, CRT etc has improved greatly in the latest 2.6.X kernels. You don't need to lock yourself into the standard modedb database. Also modedb is used only for selecting a particular resolution. The structure used to define the display panels behavior is struct fb_monspecs. Take a look at it in fb.h. I'm interested if I got all the needed data from the EDID about a display panel.

Here is basically what you have to do to handle mode setting:

1. Does the displaying hardware tell you data about itself? You have to ask yourself can I get display hardware information. If it does what format is it in. In most hardware today you can get data about the display hardware in a EDID block format. Usually that data is retrieved via i2c. Fbdev driver writers must write the code handling getting the display hardware's data. Once you have the EDID data block you can use already written functions to parse the EDID block.

   If you display hardware does not use EDID format then the driver writer must parse the data himself. What data needs to get generated? This is covered next.

2. Attempt to generate the struct fb_monspecs data. Now it is not a absolute requirement but it sure does help. There is one per physical display. This means for cases like laptops you can have one framebuffer's data being displayed on two physical displays (attached CRT and the LCD panel). In this case you would have two struct fb_monspecs per struct fb_info. When you are going to change the video mode you would have to valid the new mode against BOTH physical displays. In fact you can get a bunch of crazy combo's. The important part is that use generate a fb_monospec if possible.

   Note that fb_monospec has a mode database in its data structure. Sometimes the display hardware will tell use what the "best" video modes are for it. Also some display hardware is limited in what it can be allow to display. SO those modes are the only ones that actually work.

   Now back to the EDID case. There is a global function that will get the monitor limits for you. This function will also build you your modedb for you!!!

   fb_get_monitor_limits(unsigned char *edid, struct fb_monspecs *specs)

   Again what if we don't use EDID. Well if you can get the display hardware information in some way it is in your best interest to create a struct fb_monspec and also the modedb attached to it. What if you can't get supported modes to build a database but you can get the monitor limits? Here are your options.

3. Okay now we "might" have our monitor data and our modedb. If we have to ask ourselves does the hardware allow the change of the resolution? If it doesn't then why do we generate a fb_monospec or a modedb. Because that data can be very useful to userland :-) If this is the case you can call fb_find_mode on your modedb if you have one and return the default struct fb_var_screeninfo that we need. If you don't have a modedb you still need to supply a default struct fb_var_screeninfo that represents the display resolution. Also you could have the case where you swap about the display. In this case you might want to create a new fb_monospec and update your var data even if you don't change your resolution. Now we are done. If you hardware can change modes then continue on.
4. Now what to do for when we want to set the graphics display. Before we consider the monitor we have to see if the new resolution request is complete. Not every fb_var_screeninfo request is complete. Often the user only is concern with xres, yres and bpp. That is it. Alot of data is missing. This is bug in many drivers that they don't fill in that data thus often when the user tried to change the resolution they ended up with a blank screen. So how do we deal with it?
5. First we can use a modedb we have to find the best fit. If not use the function fb_get_mode in fbmon.c.

6. Now that we have the purposed mode we call the function

   fb_validate_mode(const struct fb_var_screeninfo *var, struct fb_info *info)

   This tells us if the requested video mode is to much for our display hardware to handle.

7. If the monitor can handle it we call the drivers xxxfb_check_var function to see if the graphics chip can handle the mode.

I hope that answers your question. Now that I wrote this I'm going to make it apart of the documenation in the kernel for a driver how to.

Your nodemask_t reminds me of something I posted to linux-ia64 last November 7, 2004, under the subject: "[PATCH preview] Adds nodemask_t for use in cpusets (NUMA memory placement)".

Chris Hellwig responded to it at the time asking why I didn't provide a single generic mask ADT, and make cpumask and nodemask instances of that.

I coded that up, but then got distracted. The remaining issue for which I didn't have a good answer was that my proposal would break the optimum handling for sparc64 or other systems that didn't handle passing structures on the stack efficiently.

Bill Irwin was a party to my discussions of that effort, so I presume that if he felt it had further merit, he would have mentioned it to you, Matthew.

Could one of you, Bill or Matthew, speak to why this generic mask ADT, underlying both cpumask and nodemask, should not be pursued further, instead of duplicating the various details of cpumask, after a global s/cpu/node/g change?

I am attaching the header file include/linux/mask.h for my current version of this mask.h, in case someone reading wants more specifics of what it is that I am referring to.

This version almost certainly does _not_ work on big endian 64 systems, due to my ignorance of how kernel bitmasks were layed out when I last worked on this mask.h header. Unlike the sparc64 performance issues with passing structs on the stack, I would hope that the big/little endian issues could be fixed without messing things up too much.

If this mask.h could actually be made to work, including on sparc64, then it would seem to be a much cleaner solution. With it, we would define cpumask_t and nodemask_t as simply:

  typedef __mask(NR_NODES) nodemask_t;
  typedef __mask(NR_CPUS) cpumask_t;

and either use operations such as mask_and() on both, or if one insisted on keeping operations that specifically called out cpumask, add some 15 trivial defines such as:

  #define cpumask_and(dst, src1, src2) mask_and(dst, src1, src2)

This is an attempt to document the various architecture specific functions that are part of KGDB. There are a number of optional functions, depending on hardware setps, for which empty defaults are provided. There are also functions which must be implemented and for which no default is provided.

The required functions are:

int kgdb_arch_handle_exception(int vector, int signo, int err_code, char *InBuffer, char *outBuffer, struct pt_regs *regs)
This function MUST handle the 'c' and 's' command packets, as well packets to set / remove a hardware breakpoint, if used.

void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Convert the ptrace regs in regs into what GDB expects to see for registers, in gdb_regs.

void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
Like regs_to_gdb_regs, except that the process in p is sleeping, so we cannot get as much information.

void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Convert the GDB regs in gdb_regs into the ptrace regs pointed to in regs.

The optional functions are:

int kgdb_arch_init(void) :
This function will handle the initalization of any architecture specific hooks. If there is a suitable early output driver, kgdb_serial can be pointed at it now.

void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char *buffer)
Write into buffer and information about the exception that has occured that can be gleaned from exceptionNo and errorcode.

void kgdb_disable_hw_debug(struct pt_regs *regs)
Disable hardware debugging while we are in kgdb.

void kgdb_correct_hw_break(void)
A hook to allow for changes to the hardware breakpoint, called after a single step (s) or continue (c) packet, and once we're about to let the kernel continue running.

void kgdb_post_master_code(struct pt_regs *regs, int eVector, int err_code)
Store the raw vector and error, for later retreival.

void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int threadid)
struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int threadid)
If we have a shadow thread (determined by setting kgdb_ops->shadowth = 1), these functions are required to return information about this thread.

This patch is an update of the original Entitlement Based Scheduler announed a few weeks ago. The patch can be downloaded from

http://sourceforge.net/projects/ebs-linux/

and applies to Linux 2.6.4.

The two main changes in this version are:

1. Interactivity has been greatly improved, courtesy of "ramp-up" dampening being applied to newly forked tasks.
2. Background tasks are now "almost background" tasks in that they are given periodic (but slow) promotion.

As before, when using this patch X should be reniced to -15.

I made many changes for cmpci.c since last release. Changes are made as follows:

1. Fix the S/PDIF out programming bug appeared in 6.16.
2. Support 8338 4-channel playback.
3. S/PDIF loop can be used after AC3 playback.
4. Legacy devices (FM, MPU401 and gameport) are served by other modules. Now the code is thinner.
5. Remove parameters setting from kernel configure menu, they can be set easily when loading the module.
6. Add spdif_out to output 44.1K/48K 16-bit stereo to S/PDIF out.
7. Add hw_copy to duplicate audio of front speakers to surround speakers.
8. Change code to minimum patch for kernel 2.6.

The attached cmpci.c in cmpci-6.64.tar.bz2 is the updated driver, and 46.diff is the patch file that needed for kernel 2.6.

The cmpci-patch-2.4.25.tar.bz2 and cmpci-patch-2.6.4.tar.bz2 are patches for kernel 2.4.25/2.6.4 tree patch, they are needed to support legacy +devices, otherwise you may ignore them.

The cmi8738.tar.bz2 contains CMI8738, which is modified from CMI8338. It describe the parameters cmi8738 can support.

The driver looks pretty good, for both 2.4 and 2.6. And the listed changes above sound OK. I see the driver is smaller now.

May I respectfully request that you submit your driver update in the form of multiple patches, one patch per email? This is the normal method of submitting changes to the Linux kernel. For example, create and send 8 patches to Andrew Morton for inclusion in the 2.6.x kernel. Each patch is applied after the last one, in succeeding order. Typical email subjects would look like

[PATCH 1/8] cmpci: fix s/pdif out
[PATCH 2/8] cmpci: support 8338 4-channel
[PATCH 3/8] cmpci: s/pdif loop
etc.

Splitting up changes in this manner allows for better verification, and makes it easier to narrow down bugs to a specific change. Large "one big patch" updates often solve many bugs, and then add a few new bugs.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm2/

• Fixed the memory leak which 2.6.5-rc2-mm1 suffered from.
• More writeback changes - correctness and performance fixes.
• Various random fixes

I have been working on a dnotify enhancement to let it work recursively and to store information about what exactly has changed.

My current code can be found here: <http://www.lambda-computing.com/~rudi/dnotify/>

From reading the list, I got the impression that there is a general consensus that the current dnotify mechanism is less than optimal, and that something should be done about it. Is that correct?

My current implementation enhances the dnotify mechanism, but is backwards compatible to the old mechanism. This is obviously the least intrusive approach, but it is also less than optimal. For example it still requires an open file handle to watch for changes in a tree, so it will create problems when unmounting a device.

In an offline discussion, the issue came up wether it would not be better to replace dnotify with a completely new mechanism like e.g. a special netlink socket. Since most userspace programs (e.g. KDE and gnome) do not use dnotify directly, but through the fam daemon, the required changes in user space applications would not be that great.

So what is your take on this? Enhance or replace?

I think everyone agrees that dnotify is a POS that needs replacement, however coming up with a good new API and implementation seems to be hard (or at least uninteresting to kernel developers).

I for sure would welcome a sane file change notification API, i.e. one that doesn't require the use of signals. However, I don't really care about recursive monitors, and I'm actually unsure if you really want the DN_EXTENDED functionallity in the kernel. It seems like a great way to make the kernel use a lot of unswappable memory, unless you limit the event queues, and if you do that you need to stat all files in userspace anyway so you can correctly handle queue overflows.

I think the most important properties for a good dnotify replacement is:

• Don't use signals or any other global resource that makes it impossible to use the API in a library thats supposed to be used by all sorts of applications.
• Get sane semantics. i.e. if a hardlink changes notify a file change in all directories the file is in. (This is hard though, it needs backlinks from the inodes to the directories, at least for the directories with a monitor, something i guess we don't have today.)
• Some way to get an event when the last open fd to the file is closed after a file change. This means you won't get hundreds of write events for a single file change. (Of course, you won't catch writes to e.g. logs which aren't closed, so this has to be optional. But for a desktop, this is often what you want.)

About recursive notification:

Some way to watch for changes on a whole file system is a must. Otherwise there is really no need to replace dnotify. When I start up KDE it watches for 256 different directories in my /home directory. It would probably watch even more directories if it could. With recursive watching it would only need to watch two or three directories recursively.

About the buffer memory usage problem:

I have been testing the current approach for a few days continuously now, and I don't get event buffer overflows even if I watch for all events on "/index.html". Of course the event buffer size should be limited. The current implementation uses 10*4096 bytes, but in most cases starting with a single 4096 byte page should be enough.

Note that the most common events (read and write) are quite small. Currently they are 32 bytes, but it would not be that hard to get them even smaller if nessecary. This is quite good compared to libraries like dazuko that report the complete path for each change.

Extended information about the type of change has been requested by many persons, and it is nessecary for many applications. People have been writing ugly syscall table hacks for this, so they must be really desperate to get this information...

It should be optional though.

Maybe adding a rate limiter on these write events would be a better idea, live updates are usefull for the desktop. Also with a netlink socket I think the overhead of many events would drop siginificantly.

Also a couple other items I think need to be on the list of features,

• Some way to not have an open file descriptor for each directory you are monitoring. This causes so many problems when unmounting, and this is really the most noticable problem for the user.
• Better event vocabulary, we should fire events for all VFS ops. I think right now it is limited to delete,create,written to. It would be good to tell the listener exactly what happened, moved,renamed, etc.

One of the big requirements for a dnotify replacement is this

• Some way to not have an open file descriptor for each directory you are monitoring. This causes so many problems when unmounting, and this is really the most noticable problem for the user.

I wanted to get some possible ideas from kernel hackers about how this could be done. Inode numbers are not unique, but is there any way to get a unique identifier on a file without using an open file? I have come up with a few ideas.. I don't think they are very good, but here is goes,

• When user passes fd to kernel to watch, the kernel takes over this fd, making it invalid in user space ( I know this is a terrible hack) then when a volume is unmounted, the kernel can walk the list of open fd's using for notifacation and close them, before attempting to unmount.
• The user passes a path to the kernel, the kernel does some work so that it can track anything to do with that path, and again when an unmount is called the kernel cleans up anything used for notification.

Both of these ideas are similar, does anyone have a better idea?

"Doctor, It Hurts When I Do It"

Seriously, dnotify sucks in a lot of ways, starting with the basic premise - that userland can do notification-based maintainig of directory tree image. It's racy by definition, so any attempts to use it for "security improvements" are scam. Which leaves us with file manglers and their ilk.

Note that any attempts to trace "aliases" in userland are hopelessly racy; that mounting/unmounting doesn't even show on the radar; that different users can see different parts of tree or, while we are at it, completely different trees; that this crap is a DDoS on a server that exports any sort of network filesystem to many clients - *especially* if you want notifications on the entire tree.

IOW, idea is fundamentally flawed and IMO the real fix is to try and figure out a decent UI that would provide what file managers are really used for.

Here goes the last -pre of 2.4.26 series.

It contains an ACPI update, SPARC/m68k/x86-64 (the latter adding basic support for Intel IA32e), amongst others.

An updated snapshot of the Enahanced MD project is now available here:

http://people.freebsd.org/~gibbs/linux/SRC/emd-0.8.0-tar.gz

and as diffs relative to the current 2.6 MD implementation:

http://people.freebsd.org/~gibbs/linux/SRC/emd-2.6-20040425-diffs.gz

A version of "emdadm" is also avaible to for this driver:

http://people.freebsd.org/~gibbs/linux/SRC/emdadm-0.00.1.tgz

This snapshot includes support for RAID0, RAID1, and the Adaptec ASR and DDF meta-data formats. Additional RAID personalities and support for the Super90 and Super 1 meta-data formats will be added in the coming weeks, the end goal being to provide a superset of the functionality in the current MD.

This drop adds the ability to create, delete, and monitor DDF and Adaptec ASR meta-data based arrays from emdadm in addition to including several bug fixes.

This release is still structured as an MD replacement. While this makes the diffs supplied above more relevant from a review standpoint, we believe that it makes more sense at this stage in EMD development to provide it as a separate driver. This change will be reflected in our next release. The hope is for EMD and MD to merge as EMD is reviewed and altered to suite the communities needs.

Given my recent work in bug fixing, and in isolating some problems to the platform rather than libata, the Silicon Image driver will be moving to beta, and the CONFIG_BROKEN marker removed, as soon as 2.6.5 kernel is out.

With the latest patches, I would say status of sata_sil is now "beta".

finally, here is our RNDIS USB Gadget Driver - see the attached patch against the gadget-2.4 BK tree as of now. It shouldn't be too difficult to port this to 2.6.

The patch adds support for Microsoft's RNDIS protocol to the standard g_ether driver. This makes it possible to connect a Linux USB gadget to any standard Windows machine and <*PALIM!*> there is a new USB network interface on the Windows side on which you can speak TCP/IP :-)

Unfortunately, although it works with the original Microsoft driver, you need an inf file on the windows side; you can download the template for that directly from M$.

Thanks to Auerswald GmbH for sponsoring this work!

There's a file system protocol used by many digital still cameras, which isn't actually camera-specific. Not MSFT-specific either.

Originally called "Picture Transfer Protocol" (PTP) it's actually more of a remote hierarchical filesystem protocol ... with an event channel (handy for "new picture" or "inserted new flash memory") and some built-in search capabilities ("what JPGs do you have"). The strangest capability was a file type tag, which isn't actually that bizarre.

As with RNDIS, and USB Mass Storage, I understand that support for PTP is part of MS-Windows since about Win2K. So a PTP gadget driver would probably be a useful contribution to Linux.

A host driver "USB PTP Storage" would be really nice too. First as a generic camera interface, second to access a gadget with the PTP interface.

(Please embarrass me by saying there already is one, I'll be so happy I won't care :-) ).

I have a PTP camera and would certainly be happy to test such a driver. Time to write it is a different matter.

These are applications, not file system interfaces like USB Mass Storage. I want to mount the camera or gadget file system and access it from any program, not run a separate app to fetch files like Mass Stor. mounts a memory device.

Why create a dedicated app like a camera interface instead of using your favorite image browser on some files?

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm4/

• CPU scheduler updates. We're heading into another big round of testing, measuring and tuning of the SMP/SMT/NUMA features in the CPU scheduler. Nick and Ingo are driving this - thanks to the people who are working with them. We really need to get this wrapped up.
• A significant number of changes to laptop-mode. If you're using this, please grab the updated startup script from Documentation/laptop-mode.txt.
• A few more tweaks to the page reclaim logic. Needs careful testing. I have one workload which seems to run faster in laptop mode (minus the readahead size increase), which is a little odd.

More work on libata... human-readable summary:

• scsi portion of command submission path now a lot more lightweight. Should reduce CPU usage a bit.
• improved documentation (see below)
• New SiS SATA driver.
• Promise: minor improvements in locking, error handling, and initialization. Promise users, please test.
• Intel ICH5: minor improvements in probing and combined mode handling. Intel users, please test.

This is going to Linus after 2.6.5 is released.

BK repositories:
http://gkernel.bkbits.net/libata-2.[46]

Patches:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.25-libata15.patch.bz2
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.5-rc2-bk6-libata2.patch.bz2

And also, there are some PDF docs generated from the source code. Although this is always available via "make pdfdocs", I also post this document at http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/libata.pdf

Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

Changes:

• updated to 2.6.4
• added documentation (readme, changelog, license, authors)
• linux/hdreg.h - 2.4 stuff
• linux/major.h - 2.4 definitions
• minor changes

README file follows:

The linux-libc-headers (llh) package (available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/) contains headers that export linux abi to userspace. These headers are a heavily modified and cleaned up version of what comes with original linux tarball. The first three digits of llh's version tag correspond to the version of linux kernel of which abi is exported, but keep in mind there are lots of 2.4 kernel compatibilities included.

Userland usefulness is achieved by removing kernel only parts (which often generate errors) and using code provided by libc where possible (this allows to avoid collisions when both linux and libc headers define the same structure or constant). Unfortunately libc dependency might result in functionality loss since libcs aren't always in sync with what kernel provides. If such a case occurs please send a bug report to the maintainer (see AUTHORS file) and, if possible, a workaround will be added. Do note that since llh is primarily for 2.6 based kernels we assume glibc to be at least version 2.3.3 (as far as I know this version wasn't released officially but is being used by many current linux distributions). Glibc is not a requirement though - llh is known to work with other implementations of standard C library - but obviously is a priority, so be prepared to send a bugreport if using something else. In case you're wondering why take such an approach if it's obvious that it might generate problems. Well, according to my knowledge there is consensus among kernel hackers as to how userland headers should look like, but unfortunately proper implementation (and wider adoption) will take time and something that just plain works (in most cases anyway) is needed now.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm5/

• A fairly small update. Mainly attempting to stabilise the CPU scheduler changes.
• A patch here which will hopefully fix the oopses which a few people have seen in the NFS server code.
• The pestiferous SMP oops in vt_ioctl() is back, and I really fixed it this time. I've a suspicion that the kernel used to have the right locking in place, but someone removed it because of some deadlock. If your kernel does appear to deadlock, please include a sysrq-T trace in the report.

I've just packaged up the latest Linux hotplug scripts into a release, which can be found at:
http://sourceforge.net/project/showfiles.php?group_id=17679

Or from your favorite kernel.org mirror at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29.tar.gz
or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29.tar.bz2

I've also packaged up some pre-built (and signed) Red Hat FC 2-test based rpms:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29-1.noarch.rpm
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-base-2004_03_29-1.noarch.rpm

The source rpm is available if you want to rebuild it for other distros or versions of Red Hat at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29-1.src.rpm

The main web site for the linux-hotplug project can be found at:
http://linux-hotplug.sf.net/ which contains lots of documentation on the whole linux-hotplug process.

This release is recommended for _anyone_ using older versions of the hotplug scripts (especially the last development snapshot) as lots of bugs have been fixed. Especially for any scsi or usb-storage users, now the proper drivers should be automatically loaded when a device is plugged in.

The release is still backwards compatible with 2.4, so there is no need to worry about upgrading.

The full ChangeLog extract since the last release is included below for those who want to know everything that's been changed, and who to blame for them :)

Many thanks to everyone who has send in patches for this release, without these submissions, this release would still contain lots of issues...

x86-64, arm, ppc64, ia64, s390 updates.

And agp, acpi, ISDN and watchdog.

Nothing earth-shattering, in other words.

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

• Dropped the tty locking fix. As predicted, it deadlocked. I also reverted the patch from bk-driver-core.patch which is causing this race to trigger more frequently.
• Added the rest of Ingo's recent CPU scheduler work. This is for people to compare with 2.6.5-rc2-mm5.

You cannot defeat me that easily!

Actually the race+oops _was_ fixed in Linus's tree a week ago, sort-of. If the race happens we end up running vcs_devfs_add() and vcs_devfs_remove() against the tty concurrently, leaving it in indeterminate state. This will cause devfs warnings and missing devfs/sysfs stuff, but no oops.

The con_open-speedup.patch in -mm reintroduces the oops by not bogusly overwriting tty->driver_data when tty->count > 1. Fun.

This rather nasty patch fixes things up again.

A ton of SATA work in the past few weeks, but not a lot terribly new in this update. The update is mainly to rediff against the latest 2.4 and 2.6 kernels. Note that this does not include experimental patches. Notably absent are

• lba48 (large transfer) requests
• splitting up Promise driver into sata_promise (tx2/tx4) and sata_sx4 (sx4) drivers.
• adding better flush-cache / writeback caching support

The above are all experimental patches I have locally.

Finally, per user requests, I have started posting the associated changelog as well.

BK repositories:
http://gkernel.bkbits.net/libata-2.[46]

2.6.x patch and changelog:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.5-rc3-libata1.patch.bz2
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.5-rc3-libata1.log

2.4.x patch and changelog:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.26-rc1-libata2.patch.bz2
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.26-rc1-libata2.log

Drivers for SATA-2 controllers have been in development, and should be making their appearance soon.

Version 1.1.0 of libsysfs, shipped as part of the sysfsutils package is now available at

http://linux-diag.sourceforge.net

Libsysfs provides a simple API to access the sysfs filesystem.

Changes in this release include:

• Lots of security auditing for buffer overflows.
• C++ compatibility fixes.
• Remove check for installed libsysfs during build.

Thanks to everyone who have been providing patches and valuable feedback.

Here is the next version of the ibmvscsi lldd. I know you were waiting for the fix that correctly checks for errors on the dma_map_foo calls, which is included. The other functional changes are to implement device_reset, and to surface a bunch of adapter attributes through shost_attrs.

This driver has been under test for the last couple of months, and is scheduled to ship in a couple of distributions shortly. There are a few bug fixes included in this patch as well, mostly in the area of abort processing and correctly handling edge conditions (freeing buffers in error paths etc.)

Comments always welcomed. I would like to get this upstream if I can, since the linux distributors are complaining slightly that it is not.

After three weeks of development, we proudly present Umbrella version 0.3 for Linux 2.6.x kernels.

--- Short version ---

Umbrella for implements a combination of process based mandatory access control (MAC) and authentication of files for Linux on top of the Linux Security Modules framework. The MAC scheme is enforced by a set of restrictions for each process.

--- What's new? ---

This release rounds up the implementation of process based restrictions. To increase performance and to make the use of Umbrella even smoother for programmers, restrictions have been devided into two levels.

Level 1 is a static set of restrictions, which is provided by The Umbrella Team. At present these is aimed at protecting a Linux system on a HP iPAQ. Level 2 is restrictions is purely defined by the programmer and applies only to the process and sub-processes that the restricted program spawns.

A short simple example of the use of this may be found in the user space program in the Umbrella 0.3 release or directly in cvs at: http://cvs.sourceforge.net/viewcvs.py/*checkout*/umbrella/umbrella-devel/userspace/src/umb_user.c?rev=1.3

Furthermore a hash table is implemented to increase flexibility and speed of the lookup of restrictions.

More details is given on the Umbrella web site: http://umbrella.sourceforge.net and on the project site http://www.sourceforge.net/projects/umbrella

--- Download Umbrella 0.3 ---

The Umbrella 0.3 kernel patch together with a user space example can be directly downloaded here: http://prdownloads.sourceforge.net/umbrella/umbrella-0.3.tar.bz2?download

--- Comments, Questions and Contributions ---

Comments, questions and contributions are most welcome! The development team can be contacted on umbrella@cs.auc.dk or in the SourceForge forums, found here: http://sourceforge.net/forum/?group_id=101217