For those running embedded pci systems the extra 35kb of wasted text strings is not really nice. Especially if you are going to have to ROM the image. For some users this could make the difference between kernel too large for lilo, and one that works.

I thought we were trying to avoid M$-thinking, or is redmond starting to influence developers, "16kb here, 32kb there, it won't matter".

This whole discussion is silly; I believe Linus has already made a decision on this issue. Namely, that /proc/pci is going to stay, because it's useful to have the ASCII text description attached to elements in the struct pci tree. Yes, this means the initialization tables take up 35k of space, but (a) that's uncompressed; and the text probably compresses quite nicely, and (b) it's __initdata, which means the space is released back to the system after the kernel boots.

That means that the only real cause of angst might be (a) trying to fit a rescue kernel on a floppy disk along with rescue tools, and (b) embedded systems. For the general case (and remember that Linus tends to like optimizing for the general case), the cost/benefit ratio for having text description of pci devices is in favor of keeping the text descriptions. I imagine if someone came up with a patch that removed the __initdata table, in the interests of embedded or rescue disk kernels, either (a) Linus would accept it, or (b) it would be trivial to maintain separately outside of the kernel. Either way, it's a lot of discussion over a fairly minor point.

It's a good point, but we may end up wanting to use different mechanisms to deal with hot-plug devices versus devices detected on boot. Yes, it's best if as much of the code path is shared as possible, but there may be enough other differences with how we want to handle hot-plug PCI that this isn't an issue.

At the very least, it's probably better to try to design a complete hot-plug solution than to make guesses about what's the best way to handle one tiny bit of the problem now. :-)

Yes. We've designed a log-structured flash FS for embedded linux (which we'll probably release next month as GPL). It is quite simple and optimal for small flashes with large sectors (normally the erase granularity for flashes is big, so you can't use a normal filesystem). I'd expect it to work for those cheaper sequential flashes as well, although I have never built anything with that.

The GC is still under tuning. As it's a log-cleaner it can obviously run pretty incremental, but the flash device's erase delay still sets the minimum latency.

All the solutions we currently have for filesystems on flash present a block device rather than a filesystem interface - that is, both FTL and NFTL act as an extra translation layer below the actual filesystem, providing 512-byte random block access for use by a traditional filesystem.

It would probably be more efficient to implement a filesystem directly on the flash, much like Microsoft's FFS2, except that FFS2 obviously isn't POSIX-compliant, and hence isn't very interesting to us, although we do have the beginnings of a filesystem driver for it.

As there are patent problems with both FTL and NFTL, it would be extremely useful to have a POSIX-compliant filesystem designed specifically for use on flash devices.

I think that there is already such a beast in existence, designed for QNX. It would be nice to either support this or write a replacement.

That is not going to work. It is too late by then. One single wrong udelay() can corrupt your data, or crash your machine [assuming broken hw. On good hw, no udelay is needed]. You should not run with wrong bogomips, not even for short periods between real change and you noticing it...

What are other possible timebases? [I'm talking i386 architecture]

• loops - thats what we have
• clock counter - changes with bogomips
• rtc - it has 32khz time base (IIRC), that gives 31usec granularity. Not enough.
• timer - it has 16bit counter, and runs 18 times a second when 65535 is used as divider. That gives me 0.84usec precission (good enough). I just wonder how long it takes to do_read_hwtimer()...

Any other ideas?

Basically, the buffercache is going to be reduced hardly more than an I/O mapping layer (with probably some extras for transactions and RAID). Caching will have to be done in the page cache.

But that's something for kernel version 2.5 (when we'll probably overhaul most of the cache stuff).

In the meantime, it would probably be best to use either your own buffer.c or accept the fact that it's not going to be as efficient as you'd like it to be.

I take personal offence from the *extremely primitive* description. The current RAID architecture supports:

1. Compatibility with *every* block device driver -- every block device can be part of the RAID array, be it SCSI, IDE, whatever.
2. Compatibility with *every* file system, which just sees the RAID array as any other block device.

The above two features are achieved especially because the RAID code sits just at the request queueing layer, above the drivers but below the buffer/page cache and filesystems.

In addition, the RAID subsysystem provides the designed redundancy, good performance, and support for hot rebuilding. The RAID-5 code, for example, includes "full stripe" write optimization, read-modify-write cycles, completion-write cycles, maintains an internal cache, etc.

Perhaps primitive, but clearly not an *extremely primitive* architecture.

The buffer cache is not intended to provide primary support for doing advanced IO control. If you want to do mirroring, then fine, do it at a different layer. We have 2 open source journaling implementations for Linux right now which work above the buffer cache, and software raid working below it. In 2.3, _all_ file write activity bypasses the buffer cache entirely. The fact that the process performing write-behind in 2.3 happens to be bdflush in buffer.c is almost incidental: it could just as easily be done at the VFS layer. Ext3 journaling on 2.2 also bypasses the buffer cache to perform IO.

The buffer cache isn't the place to provide mirroring. Do it above or below. Why wouldn't a low-level mirroring driver below ll_rw_block do what you want? Even if it didn't, you could achieve the same effect within the page cache using specialised write-back routines.

The main lack in this area is one you pointed out in an earlier email --- the lack of any way for the VM to request that the owner of an arbitrary page of the page cache or buffer cache release that page prevents easy memory balancing between cache consumers. We're discussing ways to deal with that in 2.3/2.5.

Actually, not at all.

The way to fix what you call "incestuous" is to just marry the two off for good. They aren't incestuous, they're just living in sin..

The buffer cache is closely related to the drivers, and will become only _MORE_ closely related to the drivers. That's because the buffer cache is quite consciously being evolved into just a driver interface for IO: the "buffer cache" is transforming away from a "cache", and into a pure "block IO interface".

So no, the buffer cache doesn't support the kind of mirroring you want, and almost certainly never will. But the page cache may eventually evolve into the direction you're looking for.

It's slightly messy, but the current layout looks so:

• d_parent: points to the parent node in the tree.
• d_subdirs: anchor of the cyclic list that goes through all children
• d_children: that's where the aforementioned list sits (i.e we have parent's d_subdirs <-> 1st child's d_children <-> 2nd child's d_children <-> ... <-> parent's d_subdirs).
• d_mounts: who overlaps it (root of the tree mounted atop of our dentry) _or_ dentry itself if it's not a mountpoint; in other words it's a step upwards.
• d_covers: opposite.
• d_inode: inode corresponding to dentry. May be NULL (for negative dentries).
• d_alias: cyclic list of dentries that have the same d_inode. It's anchored in the d_inode->i_dentry. This looks like d_parent/d_children/d_subdirs structure. Warning: it's badly abused in several filesystems and it is going to change. d_inode will stay as it is, but you will be safer if you'll stay out of the d_alias (and i_dentry in struct inode).
• d_hash: hash chains. Anchored in hash table.
• d_count: reference counter. Number of pointers to dentry. Pointers from cyclic lists do not count.
• d_name: name of dentry.
• d_op: methods.
• The rest: bloody mess.

Notice that:

1. we can't handle more than one dentry for a directory. VFS does not allow that, partially due to the d_alias abuse in NFS and friends.
2. _all_ work with dcache still requires big lock. Again, fixing that will require cleanup of d_alias/i_dentry mess.
3. we have only two states for dentry - hashed and unhashed. Life would be much easier if we had finer separation (e.g. special case for dentry in process of lookup()). To be changed.
4. all locking is done on inode level. It makes race prevention much harder.
5. cached_lookup() acts funny if we find a directory dentry _and_ attempt to revalidate it gives negative. Compare with the case of non-directory. Handling of invalidation is tied with the d_alias/i_dentry problem - same offenders hold the thing. It will take a large and nasty rewrite.

Actually, I've always hated the notion of "public" versus "private", and I think "serialP.h" is just a band-aid around a real problem which is that there is quite a lot of incestuous knowledge about the tty layer and serial devices all over the place.

First off, if it's really a _private_ header file, then it shouldn't be in <linux/serialP.h> in the first place. It should be in drivers/char, and you should use #include "16550.h" to make it clear that (a) it's not about "serial devices", it's about a specific _class_ of serial devices and (b) it's really just private to a specific driver (or two similar drivers), and not a generic Linux header file.

Btw, calling the dang thing "16550.h" may be technically inaccurate (it obviously is used a lot more chips than the 16550), but I think it is _psychologically_ a lot closer to what you seem to have in mind for the use. It would tell people what the file is about - which the current name does not at all. The current name probably makes most people think that the programmer was spastic and wrote an extra 'P' by mistake.

But I don't care all that much. I think that either we should do the one-liner to make existing things happy as things stand (which is basically what Alan did), or we should just fix the thing _right_, in which case the "serialP.h" file goes away - moved or integrated, I don't much think there is all that much of a difference (the integration should be much more complete, with a "serial device layer" kind of support structure etc).

I thought you all might want to know: Almost all Linux kernels today are infringing on US patent #5,806,063. The infringing code is in linux/arch/i386/kernel/time.c:get_cmos_time. It deals with using 'windowing' to convert non-y2k-ok dates into 4 digit dates.

Nevermind the fact that Linux had this code more then a year before the patent was applied for. :)

How does the GPL look opon this, can I still distribute Linux since I dont agree with the patent? If I (as say a linux distro) license the patent (to cover my ass) could I still distribute Linux?

If the patent license you get covers redistribution by the people who get copies indirectly from you, that is consistent with the GPL. However, if the license does not cover this, if you would not be able to extend that permission to redistributors, you would not be able to distribute in a way that satisfies the GPL.

The situation is the same whether you are distributing just Linux or a whole Linux-based GNU system.

I don't think you need to worry about getting a license for this particular patent, though.

As a former Patent Examiner, I feel that I can shed some light on patents. Someting to keep in mind when looking at them is the claims. Claims are really the major part of a patent that have any relevance.

Claims 1 and 11 are the independant claims and both of those claims specifically state "A method of processing dates in a database,..."

Does the linux kernel use a database? (retorical q here) I think not .. thus this patent is irrelevant to what is being done in kernel code.

However all the compaines that are using 'pivit logic' with databases are at risk of possible infringement. Now even if you have proof of this logic in the linux kernel one must prove that it is obvious to use such logic within a database. Seeing as just about eveyone in the industry uses this kind of logic in there database apps, I'd say it was not rocket science but I am not an attourney 'I have legs' (LOL).

Personally I am ammazed at what people today call novel and want patent protection over. Companies want to patent there data structures.. no joke a certain co in a certain northwest state was and probably still is trying this. I had to leave that place cause my waders were not tall enough.

So next patent you see read the claims carefully first and look for the independant claims as they are the 'meat'. The rest of the patent is there for clairification as to what the claims are referring to and for the legal b******t that goes into patents.

Be careful there! You do NOT want to raise the issue with the PTO! Under their administrative rules, they can review the patent and only the patent hold is allowed to present "evidence" and challengers are not permitted any standing or any position to counter that evidence. If they "win" the review, which they often do, that fact is then admissible in court. At least one individual was known to try and get people to challenge him at the PTO knowing full well that he would lose in open court. After winning an administrative ruling, he then held the advantage in subsequent court challenges and had an improve chance of winning at court.

You are generally better off challenging a patent in court FIRST before any PTO review.

the best thing to do is ignore it. Let the patent holders try to sue us first, at which point it can be defeated pretty easily.

It would be interesting for someone to set up a www.priorart.org web site, dedicated towards finding and exposing stupid USPTO tricks; the problem is that it would be a legal lightening rod, and it would have to be careful to disclaim that it was giving anything that might be construed as legal advice, or inducements to infringe patents (valid or otherwise); but just as a data repository of data that might or might not be accurate. Followups on this should go elsewhere, as it's not really a kernel issue.

If anybody's interested, I can provide source-code, dated in the first part of this decade (1991), that uses the obvious "windowing" mechanism to set the century byte of the CMOS chip. This is used in the Analogic 2030 arbitrary function generator. I wrote the BIOS. This source-code is proprietary, however, to support a petition against MD, it could certainly be referenced and possibly forced into evidence if a complaint ever went that far.

Just because a patent was issued, it does not mean it's valid. If the patent holder is informed that your use predates his, and it becomes obvious that there was prior art not cited in the application, the patent holder will usually issue an "unrestricted license" so that nobody has to show patent validity or otherwise.