[2.6] The List, pass #2

I've reorganized the list into 5 categories based on the feedback I received. Now let's see what happens :-)

In line with your expectations?

-- Guillaume

----------------------------------------------------
Likely to be merged before feature freeze:

o New VM with reverse mappings
o Add Linux Security Module (LSM)
o New MTRR (Memory Type Range Register) driver
o Add support for CPU clock/voltage scaling
o Add User-Mode Linux (UML)
o Direct pagecache <-> BIO disk I/O
o Fix device naming issues
o Remove the 2TB block device limit

----------------------------------------------------
"The pressure is on! (TM)":
(either gets merged before feature freeze or has to wait till 2.7)

o Rewrite of the console layer
o XFS (A journaling filesystem from SGI)
o LVM (Logical Volume Manager) v2.0
o Zerocopy NFS
o Asynchronous IO (aio) support
o New kernel build system (kbuild 2.5)
o Serial driver restructure
o Replace initrd by initramfs
o ext2/ext3 large directory support: HTree index

----------------------------------------------------
Can be merged after the feature freeze and before the 2.6 release:

o Strict address space accounting
o More complete NetBEUI stack
o Add hardware sensors drivers
o PCMCIA Zoom video support
o Change all drivers to new driver model
o UDF Write support for CD-R/RW (packet writing)
o USB gadget support

----------------------------------------------------
Would be nice to have before feature freeze, but most likely 2.7:

o Improved i2o (Intelligent Input/Ouput) layer
o Read-Copy Update Mutual Exclusion
o New IO scheduler
o Per-mountpoint read-only, union-mounts, unionfs
o EVMS (Enterprise Volume Management System)
o Dynamic Probes
o Page table sharing
o ext2/ext3 online resize support
o Better event logging for enterprise systems
o UMSDOS (Unix under MS-DOS) Rewrite
o Scalable Statistics Counter
o Linux Kernel Crash Dumps
o SCTP (Stream Control Transmission Protocol)
o High resolution timers
o Overhaul PCMCIA support
o Reiserfs v4
o New lightweight library (klibc)
o New mount API
o Generic parameter/command line interface
o Full compliance with IPv6
o Serial ATA support
o Add support for NFS v4

----------------------------------------------------
Definitely 2.7:

o InfiniBand support
o Add thrashing control
o Remove all hardwired drivers from kernel

Given the interest shown the last time you thought about removing it, I think it would be appropriate to add LTT back again.

Cheers,

Karim

===================================================
                 Karim Yaghmour
               [email protected]
      Embedded and Real-Time Linux Expert
===================================================

this has been done for almost a year now, what is holding it up?

/**************************************************
**   Mark Salisbury       ||      [email protected]     **
** If you would like to sponsor me for the       **
** Mass Getaway, a 150 mile bicycle ride to for  **
** MS, contact me to donate by cash or check or  **
** click the link below to donate by credit card **
**************************************************/
https://www.nationalmssociety.org/pledge/pledge.asp?participantid=86736

I resisted playing devils advocate yesterday, but I just cant do it anymore :-) Does anyone want to speculate as to how many feature freezes we will have this time around? Historically the kernel release cycle has been an interesting process. I remember jumping to version 0.95 because 1.0 was really close, maby even ready by Christmas....

Jim

PS: Please dont take this as a criticism of anybody. I certainly couldnt
do any better. Its just funny to remember all the times we have done this before and how it has always worked out.

On Fri, 19 Jul 2002 00:47:37 -0400
"Guillaume Boissiere" <[email protected]> wrote:

[SNIP]

[SNIP]

Does this mean native Serial ATA controllers? There's already a Serial ATA board out using the HPT372A + an 88i8030 bridge that claims to be Linux-compatible.

(See http://www.watch.impress.co.jp/akiba/hotline/20020719/serialatarai.html
for pictures and Japanese commentary.)

Ugggggggggggh.

I'm not looking forward to having my kernel split into hundreds of files, and the overhead of the kernel having to individually load every driver that's essential to system operation.

Much better format.

Is this something which has not been forward ported from 2.4 to 2.5? Or is there a serious problem which hasn't bitten me?

Hopefully the core parts of this could make 2.5, allowing final corrections later.

Sorry to repeat, this seems to be a feature which will be in many if not most other systems before any possible release date for 2.8. Is it really that far out? (that's a status request, not a statement)

I really hope this means drivers MAY be used as modules, not MUST. There is some overhead in doing things as modules, and added complexity usually means "harder to debug." Particularly with modules where there can be corner conditions and races on [un]load.

Again, thanks for the status!

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Given that work on a GPL-compatible NFSv4 implementation hasn't even started yet as far as I know it's very unlikely that it will be in 2.6.0.

Thanks. Not what I wanted to hear, but clearly it's unlikely unless someone jumps up and say "I have one all done would you like it?"

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Let me repeat: there is no GPL-compatible NFSv4 implementation I know of. And no, CITI's 3clause-BSD doesn't qualify as GPL-compatible.

> On Wed, Jul 31, 2002 at 01:43:15PM -0400, Bill Davidsen wrote:
>> > o Add support for NFS v4
>>
>> Sorry to repeat, this seems to be a feature which will be in >> many if not most other systems before any possible release date >> for 2.8. Is it really that far out? (that's a status request, >> not a statement)

> Given that work on a GPL-compatible NFSv4 implementation hasn't > even started yet as far as I know it's very unlikely that it > will be in 2.6.0.

In that case I suggest you check the Linux Kernel archives again. The CITI folks have been working on this for at least 2 years now. There are beta versions both for Linux, and BSD, and the former has indeed been announced both on this list and on the Linux Fsdevel list.

IIRC, the GPLed version was in fact pretty much of a necessity in order to get the IETF to consider NFSv4 as an internet standard: for that you need at least 2 independent implementations (SunOS + Linux are the showcases)

Cheers,
Trond

And I think their reuse of the Linux NFS code could be claimed to be GPL violation. But it's Olaf's/yours/others code, not mine.

> On Wed, Jul 31, 2002 at 10:20:41PM +0200, Trond Myklebust > wrote:
>> In that case I suggest you check the Linux Kernel archives >> again. The CITI folks have been working on this for at least 2 >> years now.

> Let me repeat: there is no GPL-compatible NFSv4 implementation > I know of. And no, CITI's 3clause-BSD doesn't qualify as > GPL-compatible.

Care to comment on why it is not GPL compatible? Given that they are interested in merging their code into the standard kernel ASAP, I know that they'd be interested in correcting any incompatibilities.

Cheers,
Trond

Bill,
Several people (IIRC including Alan Cox) would like to make many of the
modules (network cards and scsi drivers for example) mandatory, requiring use of an initrd (or it's replacement) on all boot setups.

check the archives from about 4 months back for the discussion.

David Lang

The 3 clause BSD though very much a completely free/open license has requirements conflicting with the GPL

http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses
http://www.fsf.org/philosophy/bsd.html

An additional problem with a BSD like license is that it makes no statement on patents - regrettably a critical issue now days in the USSA. That means nothing prevents CITI from providing BSD licensed code and then 6 months later sueing everyone who used it. I don't see CITI doing that but the basic problem is still there.

If it is all their own code, and they want to have a BSD licensed copy for other reasons - eg to merge the same code into BSD, sell it to proprietary vendors or whatever, then it would be immensely saner if they would submit a copy for the Linux kernel under the GPL and keep it dual licensed. As the owner of a work they can license it many many ways all at the same time.

The random driver has a nice example of this.

Alan

The "original BSD license" listed on that page actually has 4 numbered clauses, number 3 (the "advertising clause") being the conflicting one. The "modified BSD license", which they link to on the same page, has 3 clauses and *is* GPL compatible. As far as I can tell, the license we are using at CITI is nearly word-for-word the "modified BSD license", and is GPL compatible.

--Bruce Fields

Well, given that the protocol specification isn't 100% finalised, it's not clear that pushing for inclusion now is entirely sensible. We don't want people to be using an NFSv4 on Linux that is incompatible in some subtle way with other vendors.

Also, I suspect that NFSv4 will be fairly localised in the changes it makes and could well go in to 2.6.10 of whatever (afterall, reiserfs went in at 2.4.2).

There are some changes that NFSv4 would like to make that affect common code, such as making open(,O_EXCL) work for a networked filesystem, but we can live without that (as we do with NFSv3), but hopefully that functionality will get in before halloween anyway.

My understanding is that the CITI team will be funneling some of their NFSv4 code though the maintainers (Trond and myself) to at least get some of the code into 2.5. This will likely not include support for all the fancy state and locking, but will support the well established aspects of the protocol and will allow minimal operability. This will also mean there is a clear base in the mainline kernel for other bits to be added as appropriate.
Obviously we will clarify the license before forwarding to Linus.

I'm particularly keen to get the crypto authentication stuff in and I will be looking into that RealSoonNow.

NeilBrown

Why?

Sure, one could get fancy, but just running SCSI or IP over InfiniBand can't be that complicated... hmmm?

Guillaume> Definitely 2.7:
Guillaume> o InfiniBand support

Albert> Why?

Albert> Sure, one could get fancy, but just running SCSI or IP Albert> over InfiniBand can't be that complicated... hmmm?

Look at http://infiniband.sf.net to see all the infrastructure required just to get to the point of being able to start to write an IP-over-IB driver.

Best,
Roland

B

As I said, "one could get fancy", thus missing the 2.6.xx kernel. It's pretty obvious that you could do SCSI and IP with much less code. What's with the "HCA DDK" anyway, UDI reborn? I see all sorts of layers for IPC and what looks like VI/VIA, etc.

Ditch the lofty goals, and you might make the 2.6.xx kernel. You can stick to being a FireWire alternative for now.

Albert> As I said, "one could get fancy", thus missing the 2.6.xx Albert> kernel. It's pretty obvious that you could do SCSI and IP Albert> with much less code. What's with the "HCA DDK" anyway, UDI Albert> reborn? I see all sorts of layers for IPC and what looks Albert> like VI/VIA, etc.

Albert> Ditch the lofty goals, and you might make the 2.6.xx Albert> kernel. You can stick to being a FireWire alternative for Albert> now.

The idea behind the HCA DDK is to let IB hardware drivers only implement the details of the hardware they support, while keeping the generic code generic. It's similar in spirit to the way Linux doesn't force ethernet drivers to implement the whole TCP stack.

Unfortunately the "VI layer" you mention is just about the lowest level it makes sense to talk to IB hardware. IB chips really do operate in terms of queue pairs, completion queues, memory regions and so on. Other stuff like path record lookup is a necessary to use an IB fabric (nodes are identify by a GUID, but packets need to be sent to a LID, and the mapping of GUID->LID is not necessarily fixed).

I agree that it's a shame that the IB spec is so absurdly complex. And it probably is true that you could come up with a simplified way of using IB hardware that would be easier to code for. However, I don't think you'll find much interest in the IB world in implementing Linux-specific, non-interoperable, non-IB-spec-compliant software.

Best,
Roland

In article <[email protected]>,

It's big, it's complex, and nobody seems to take it that seriously (the only people who ever asked _me_ about it was Intel, and they seem to have cancelled their own projects).

If it turns out to be a big hit, it can be backported. But as it looks now, it has very little relevance for any 2.6 freeze schedule.

Linus

True, and to second that with some facts, companies who were making this their mainstay, are in much pain, on top of their economic status, because of Intel seemingly cancelling their projects.

Several companies in Austin, TX were chomping at the bit for people to come work on Infiniband technology, but there has been nothing new relating to this climate for a very long time...and probably won't be unless Intel, HP, IBM, someone with deep pockets and a marketing machine can show it's viable for consumer use.

Austin Gonyou <[email protected]>

As far as I know, they plan on doing things like disk partition detection outside the kernel, i.e. in a userspace program. That clearly require
a initrd (or similiar) for anybody with root on a partitioned disk.

Lots of other bootup initialization, like DHCP, might move to userspace as well. This gives a smaller and safer kernel.

I cannot see this requiring modules though. Even a kernel without any module support at all should work fine for those who compile their own. Redhat and other distributors may be interested in shipping a completely modular kernel that loads modules from that initrd, but that certainly won't be a _requirement_ for all kernels.

Helge Hafting

Sure something prevents them. You can't induce people to violate your patent
and then complain when they do what you induced them to do. Remember Rambus?

DS

You don't have to induce them, you just announce release 1 and wait for someone to pick it up and merge it.

Intel canned their hardware, Microsoft apparently canned support in their upcoming product short term, nobody has a ready to go stack.

SCSI over infiniband should work nicely with little work. IP over infiniband is a bit more complicated, at least until they actually implement the congestion control in the fabric

I don't know about that. But I don't accept the claim that the GPL's statements on patents adds any additional protection against a copyright-owner later deciding to pursue a patent. Here's the relevant clause of the GPL:

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

Note that the "you" referred to in this clause is the licensee, not the copyright owner. Thus the effect of this clause is only to prevent licensees from redistributing a work with patent problems.

In the case of a contributor to a project like the Linux kernel, however, two things are happening at once:

1. The contributor is creating original works which are copyright to that contributor.
2. The contributor is creating a derived work of the Linux kernel, which is copyright to a whole bunch of other people.

The only thing that permits a contributor like CITI to create and distribute derived works of the Linux kernel is the contributor's acquiescence to the GPL on *other* people's works. So if CITI a year from now decided to start collecting royalties on some hypothetical patent, it would be violating the GPL on other people's code; the license on the particular files that CITI added would be irrelevant.

Feel free to correct me if I've missed something here. --Bruce Fields

I read that Microsoft was cancelling support for it as well.

Ben

Ben Greear <[email protected]>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Ah, the austin rumor mill.

According to a friend of mine who works at AMD:

1) Intel licensed that hyper-transport thing when they licensed x86-64 (Yamhill?).

2) Dell gave people refunds on the few itanium machines they actually managed to sell. (I believe the number I heard was a total of about two hundred and fifty total itanium "development" systems sold...)

There would appear to be a distinct trend here, but you know rumors... :)

Rob

Hi!

Why *safer*? Partition (,DHCP,..) code is ran once at boot. It is hard for it to harm security.
Pavel

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

I wouldn't worry about partition detection, but network stuff is always risky. A "bad guy" could listen for DHCP and try to fake a response or do a buffer overflow.

Userspace programs are supposedly easier to fix, and a messed-up userspace isn't quite as bad as a messed up kernel when an attacker tries to get in.

I think kernel simplicity is the main driving factor here though. Things that _can_ be done in userspace without major trouble should be done in userspace. And of course there's embedded users who actually want to save the space currently used by partition detection etc. No need for that when
all your fs'es are on eprom. No need in a diskless workstation either.

Helge Hafting

On Fri, 2002-07-19 at 05:47, Guillaume Boissiere wrote:

Missed this originally

Improved I2O will make 2.6. The code in 2.5 is way behind 2.4 and basically doesn't work. It also needs no core changes affecting anything outside of I2O so its a driver item not a core feature by Oct 31

This should be in 2.4 soon. It will be essential by the time 2.6 is out. I don't know what Martin's plans are for it, but again its pure driver code so not a core issue

I don't really care about DHCP, but anything needed for booting is sure better off in the kernel. It can be a compile option for the embedded folks, but I suspect the code to call the user program is about as large as the code to actually check the partitions.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Followup to:  <[email protected]>
By author:    Helge Hafting <[email protected]>
In newsgroup: linux.dev.kernel

Perhaps more relevantly:

a) User-space code is easier to write; consider memory management in particular.

b) If the user-space process has gotten compromised or corrupted, it still goes away when it exits. In the kernel, any corruption stays around forever.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>