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
Guillaume Boissiere wrote:
>
> 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
===================================================
Karim Yaghmour
[email protected]
Embedded and Real-Time Linux Expert
===================================================
On Friday 19 July 2002 00:47, Guillaume Boissiere wrote:
> o High resolution timers
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
On Fri, Jul 19, 2002 at 12:47:37AM -0400, Guillaume Boissiere wrote:
> ----------------------------------------------------
> Likely to be merged before feature freeze:
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]
> ----------------------------------------------------
> Would be nice to have before feature freeze, but most likely 2.7:
>
> o Serial ATA support
[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.)
On Fri, Jul 19, 2002 at 12:47:37AM -0400, Guillaume Boissiere wrote:
> o Remove all hardwired drivers from kernel
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.
On Fri, 19 Jul 2002, Guillaume Boissiere wrote:
> I've reorganized the list into 5 categories based on the feedback
> I received. Now let's see what happens :-)
Much better format.
> ----------------------------------------------------
> "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)
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?
> ----------------------------------------------------
> Would be nice to have before feature freeze, but most likely 2.7:
>
> o Full compliance with IPv6
Hopefully the core parts of this could make 2.5, allowing final
corrections later.
> 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)
>
> ----------------------------------------------------
> Definitely 2.7:
>
> o InfiniBand support
> o Add thrashing control
> o Remove all hardwired drivers from kernel
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.
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.
On Wed, 31 Jul 2002, Christoph Hellwig wrote:
> 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.
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.
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.
On Wed, Jul 31, 2002 at 09:23:08PM +0100, Christoph Hellwig wrote:
> 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.
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.
>>>>> " " == Christoph Hellwig <[email protected]> writes:
> 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
>>>>> " " == Christoph Hellwig <[email protected]> writes:
> 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
> > o Remove all hardwired drivers from kernel
>
> 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.
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
On Wed, 2002-07-31 at 21:34, Trond Myklebust wrote:
> 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.
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
On Thu, Aug 01, 2002 at 01:31:44AM +0100, Alan Cox wrote:
> On Wed, 2002-07-31 at 21:34, Trond Myklebust wrote:
> > 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.
>
> 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
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
On Wednesday July 31, [email protected] 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)
>
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
Guillaume Boissier writes:
> Definitely 2.7:
>
> o InfiniBand support
Why?
Sure, one could get fancy, but just running SCSI or IP
over InfiniBand can't be that complicated... hmmm?
>>>>> "Albert" == Albert D Cahalan <[email protected]> writes:
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
Roland Dreier writes:
> >>>>> "Albert" == Albert D Cahalan <[email protected]> writes:
B
> 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.
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" == Albert D Cahalan <[email protected]> writes:
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]>,
Albert D. Cahalan <[email protected]> wrote:
>Guillaume Boissier writes:
>
>> Definitely 2.7:
>>
>> o InfiniBand support
>
>Why?
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
On Thu, 2002-08-01 at 00:08, Linus Torvalds wrote:
> In article <[email protected]>,
> Albert D. Cahalan <[email protected]> wrote:
> >Guillaume Boissier writes:
> >
> >> Definitely 2.7:
> >>
> >> o InfiniBand support
> >
> >Why?
>
> 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).
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]>
David Lang wrote:
>
> > > o Remove all hardwired drivers from kernel
> >
> > 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.
>
> 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.
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
>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.
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
On Thu, 2002-08-01 at 10:33, David Schwartz wrote:
>
> >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.
>
> 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?
You don't have to induce them, you just announce release 1 and wait for
someone to pick it up and merge it.
On Thu, 2002-08-01 at 02:56, Albert D. Cahalan wrote:
> Guillaume Boissier writes:
>
> > Definitely 2.7:
> >
> > o InfiniBand support
>
> Why?
>
> Sure, one could get fancy, but just running SCSI or IP
> over InfiniBand can't be that complicated... hmmm?
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
On Thu, Aug 01, 2002 at 02:42:55PM +0100, Alan Cox wrote:
> On Thu, 2002-08-01 at 10:33, David Schwartz wrote:
> >
> > >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.
> >
> > 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?
>
> You don't have to induce them, you just announce release 1 and wait for
> someone to pick it up and merge it.
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
Linus Torvalds wrote:
> In article <[email protected]>,
> Albert D. Cahalan <[email protected]> wrote:
>
>>Guillaume Boissier writes:
>>
>>
>>>Definitely 2.7:
>>>
>>>o InfiniBand support
>>
>>Why?
>
>
> 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.
I read that Microsoft was cancelling support for it as well.
Ben
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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
On Thursday 01 August 2002 02:10 am, Austin Gonyou wrote:
> 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.
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
> 2) Dell gave people refunds on the few itanium machines they
> actually managed to sell.
> There would appear to be a distinct trend here, but you know
> rumors... :)
In this case, rumors are completely untrue. :-) Standard Operating
Procedure is to give refunds for systems returned within 30 days if the
customer chooses to do that. We didn't do anything akin to a recall. In
fact, we're still selling 4P Itanium servers (PowerEdge 7150).
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001 and Q1/2002! (IDC May 2002)
Hi!
> > > > o Remove all hardwired drivers from kernel
> > >
> > > 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.
> >
> > 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.
>
> 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.
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.
Pavel Machek wrote:
> > Lots of other bootup initialization, like DHCP,
> > might move to userspace as well. This gives a smaller
> > and safer kernel.
>
> Why *safer*? Partition (,DHCP,..) code is ran once at boot. It is hard for
> it to harm security.
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
> o Improved i2o (Intelligent Input/Ouput) layer
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
> o Serial ATA support
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
On Thu, 8 Aug 2002, Helge Hafting wrote:
> Pavel Machek wrote:
>
> > > Lots of other bootup initialization, like DHCP,
> > > might move to userspace as well. This gives a smaller
> > > and safer kernel.
> >
> > Why *safer*? Partition (,DHCP,..) code is ran once at boot. It is hard for
> > it to harm security.
>
> 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.
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
> >
> > Why *safer*? Partition (,DHCP,..) code is ran once at boot. It is hard for
> > it to harm security.
>
> 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.
>
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]>