Re: [2.6] Most likely to be merged by Halloween... THE LIST

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Val Henson]

On Thu, 18 Jul 2002, Dave Jones wrote:

> > > o Add support for NFS v4                          (NFS v4 team)
> >      This really shouldn't wait for 2.8!
>
> Last I saw of this patch it was still against something like 2.4.1,

Perhaps we're thinking of different projects, but the current patches
from CITI are against 2.4.18:

http://www.citi.umich.edu/projects/nfsv4/

Whether they've ported to 2.5.x lately is another question.

Thanks to Cynthia Wong (an NFSv4 hacker) for pointing this out to me.

-VAL

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Ben Rafanello]

On Fri, Jul 26, 2002 at 3:16AM Joe Thornber wrote:
>On Thu, Jul 25, 2002 at 12:36:45PM -0500, Ben Rafanello wrote:
>> This will work well for
>> cases where the metadata for the volume/volume group does not have to be
>> updated at runtime.  However, it appears that device mapper needs a
>> kernel module to handle those cases where the volume metadata must
>> be updated during runtime (cases such as RAID 5, Mirroring -
>> particularly the fancier forms with features like smart resync
>> and hot spot mirroring, bad block relocation, etc.).
>
>If you need to change the mapping all you have to do is suspend the
>device, load a new map, and then unsuspend the device.  This can be
>done from within the kernel, or from userland via the ioctl interface.
>
>There is a facility enabling targets to notify userland processes of
>events.  eg, a mirror has completed its initial sync, a bad block has
>occured, etc.
>

For cases where the metadata does not have to be changed frequently,
this may be acceptable.  Bad block relocation is not performance
critical - it is (hopefully) a rare event.  So having the BBR
metadata updated from userspace is probably acceptable.  However,
lets look at mirroring.  In particular, mirroring with smart
resync.  What is happening here is that a mirror is removed from
a mirror set with the expressed (or implied) intention to return
it to the mirror set at some point in the future.  This is typically
done to use the removed mirror as a source for a backup while the
rest of the mirror set continues to accept updates.  While the
removed mirror is out of the mirror set, the volume manager
tracks which blocks have changed in the mirror set so that when the
removed mirror is returned to the mirror set, only the blocks that
have changed need to be sync'ed.  This is typically done using a
bitmap in the metadata with one bit per block in the mirror.  Much
like snapshots and their cow tables, the changed blocks bitmap must
be updated and written to disk before a block is modified.  This
can't be done from userspace for many of the same reasons that
snapshot metadata updates are not done from userspace.  In general,
when you have metadata that must be updated frequently, or when
I/O to a device must be suspended until a metadata update is completed,
having the metadata updated from userspace is .... troublesome at best.
Of course, I haven't gone into the striping with parity case yet
either, which would be another example of the metadata update
problem just discussed.

On the facility used to notify userland processes of events, how
are the userland programs notified?  Does bad block relocation
have to have a daemon associated with it so that it can receive
notification of bbr events, or does the notification facility
launch a bbr provided program to handle this?  Or does the
notification facility accept plug-in modules to handle events?
Or is some other mechanism used (I haven't thought to much about
this yet so what follows are just some random ideas that popped
into my head).  If every volume management function needs its
own daemon to handle these notifications, that could get messy.
If the handler launches a program, then you have obvious performance
implications as well as deadlock issues (I/O is suspended pending a
metadata update, but the program to do the update in userspace must
be loaded from the volume where I/O is suspended ... ).  If the
notification facility accepts plug-in modules, are the plug-in
modules always loaded or are they only loaded when needed?  If
part of the notification facility is swapped out and is needed, you
could again have the deadlock issue.  Of course, most of these
issues go away or are more easily solved if they are dealt with in
the kernel, which is probably why you implemented your snapshot
support in the kernel. Hmmm ... I'll have to think about this
some more when I get the time.

>> Thus, to
>> support AIX (or any other enterprise level volume manager since
>> they all tend to have similar features) would require more than
>> "just a little bit of userland code", it would require a significant
>> amount of kernel code as well.
>
>No this can all be done from userland.

I think you are mistaken here.  I don't think it can be done completely
from userland for reasons just discussed.

>
>
>- Joe

Ben Rafanello
EVMS Team Lead
IBM Linux Technology Center
(512) 838-4762
benr@us.ibm.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Joe Thornber]

On Fri, Jul 26, 2002 at 11:12:15AM -0500, Ben Rafanello wrote:
> Much
> like snapshots and their cow tables, the changed blocks bitmap must
> be updated and written to disk before a block is modified.

Agreed dirty region logging will be handled directly by the in kernel
mirror target, in the same way that the snapshot exception table is
handled by the snapshot target.

I guess when I think of metadata I'm really thinking of the mappings
that describe whole volumes, rather than any internal data that a
particular target may use.  I think this is an appropriate divide,
presumably EVMS stores the dirty bitmap for a mirror in the same way
irrespective of whether the volume group metadata is in AIX or LVM1
format ?

> On the facility used to notify userland processes of events, how
> are the userland programs notified?

There are 2 ioctls, one which gets the status for all the targets in a
device, and another that blocks until that status changes.  It is up
to the target implementor to decide what is returned in the status,
and to declare when this status has changed.

So you will need a daemon if you are waiting for an event.  For
instance pvmove needs no additional kernel code to be implemented,
instead it just uses a mirror target to keep the old and new mappings
in sync.  When the mirrors initial sync has been completed pvmove
notices the change in status, removes the mirror and updates the
device to use the new mapping.

- Joe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Ben Rafanello]

On Tues, Jul 23, 2002 at 3:10 am, Joe Thornber wrote:
>On Mon, Jul 22, 2002 at 01:31:11PM -0500, Ben Rafanello wrote:
>> I believe you are referring to Device Mapper, which could, in theory,
>> handle the AIX metadata layout.  However, AFAIK, there are no tools
>> currently available or under development for Device Mapper to make
>> this happen.  Currently, EVMS is the only way to read/write to AIX
>> volumes under Linux.
>
>This is absolutely correct, LVM2 does not currently support AIX
>metadata.  However the LVM2 tools were designed to support multiple
>metadata formats, and it really would be very little work to write the
>code to do this (after all this is just a little bit of userland code,
>rather than kernel code in EVMS).  ATM Sistina are not willing to pay
>for this work, so it will have to come from some other part of the
>community.

After a quick look through the device mapper code, it appears that
device mapper knows nothing of the metadata format of the
volumes/partitions/etc. that it is mapping.  This will work well for
cases where the metadata for the volume/volume group does not have to be
updated at runtime.  However, it appears that device mapper needs a
kernel module to handle those cases where the volume metadata must
be updated during runtime (cases such as RAID 5, Mirroring -
particularly the fancier forms with features like smart resync
and hot spot mirroring, bad block relocation, etc.).  Thus, to
support AIX (or any other enterprise level volume manager since
they all tend to have similar features) would require more than
"just a little bit of userland code", it would require a significant
amount of kernel code as well.

>There is a little tool called dmsetup:
>
>http://people.sistina.com/~thornber/dmsetup_8.html
>
>that is essentially a very simple volume manager.  But it does give
>you full access to all the facilities of device-mapper.  eg, I just

Thanks for the link!  I'll give it a try.


Ben Rafanello
EVMS Team Lead
IBM Linux Technology Center
(512) 838-4762
benr@us.ibm.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Joe Thornber]

On Thu, Jul 25, 2002 at 12:36:45PM -0500, Ben Rafanello wrote:
> After a quick look through the device mapper code, it appears that
> device mapper knows nothing of the metadata format of the
> volumes/partitions/etc. that it is mapping.

This is deliberate, device-mapper maps devices, it does _not_ read 101
metadata formats.

With EVMS you have decided you want to read/write the metadata from
within the kernel.  That's fine, I think the jury's out at the moment
regarding whether the extra overhead of maintaining more kernel code
is offset by avoiding an initrd when placing root on an LV.

What I _do_ object to is that EVMS does not factor out seperate
interfaces/subsystems that can be used by appplications other than
EVMS.  This is why I say you are just embedding an application in the
kernel (as did LVM1), rather than providing a set of generic services.

> This will work well for
> cases where the metadata for the volume/volume group does not have to be
> updated at runtime.  However, it appears that device mapper needs a
> kernel module to handle those cases where the volume metadata must
> be updated during runtime (cases such as RAID 5, Mirroring -
> particularly the fancier forms with features like smart resync
> and hot spot mirroring, bad block relocation, etc.).

If you need to change the mapping all you have to do is suspend the
device, load a new map, and then unsuspend the device.  This can be
done from within the kernel, or from userland via the ioctl interface.

There is a facility enabling targets to notify userland processes of
events.  eg, a mirror has completed its initial sync, a bad block has
occured, etc.

> Thus, to
> support AIX (or any other enterprise level volume manager since
> they all tend to have similar features) would require more than
> "just a little bit of userland code", it would require a significant
> amount of kernel code as well.

No this can all be done from userland.

- Joe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Ben Rafanello]

On Mon, Jul 22, 2002 at 11:23:42 Joe Thornber wrote:
>On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
>> o EVMS (Enterprise Volume Management System)      (EVMS team)
>> o LVM (Logical Volume Manager) v2.0               (LVM team)
>
>Some comments on the 'EVMS vs LVM2' threads:
>
>I am only petitioning for the driver called 'device-mapper' to be
>included in the kernel.  This is a *much* lower level volume manager
>than either the EVMS or LVM1 drivers.  I am *not* petitioning for EVMS
>not to be included.
>
My position is similar - I would like to see EVMS in the kernel.  I
certainly would not mind seeing device mapper go into the kernel as
well.  EVMS was designed to appeal to the corporate user and to play
in the enterprise computing environment.  The goal was to make Linux
more attractive to users in this environment, and this determined much
of its look and feel, as well as its feature set.  However, enterprise
computing is just one of the environments where Linux is found.  While
what we have done to appeal to the enterprise user will be attractive
to other users as well, it is not a 'one size fits all' solution.
Similarly, Device Mapper appeals to a certain set of users and
applications as well.  Given this, I think that both should be included.

>People are getting understandably confused between device-mapper and
>LVM2:>
>
>*) device-mapper is a driver, intended to provide an extensible (via
>   the definition of new targets) framework capable of support
>   *anything* that volume management applications should want to do.
>

Are you working with Jeff Garzik?  It sounds like he is working on
something similar to device mapper for partition management.

>*) LVM2 is a userland application that uses the device-mapper driver to
>   provide a set of tools very similar to LVM1.  Currently LVM2 is the
>   only userland application that uses this driver, leading people to
>   associate the two far too strongly.
>
>It would be good if other volume managers embrace device-mapper
>allowing us to work together on the kernel side, and compete in
>userland.

Having multiple volume managers use device mapper, each without
being aware of the others, will lead to chaos.  This is why EVMS
is designed the way it is - so that we can safely have multiple
user interfaces/volume managers coexist.  This is where the real
work is.

>Kernel development takes *far* too much manpower for us to
>be duplicating work.

Our experience has been a little different - the kernel code was the
least of our worries.  The userspace code has been far more taxing ...

>For example I released the LVM2 vs EVMS snapshot
>benchmarks in the hope of encouraging EVMS to move over to
>device-mapper,

This is much easier said than done.

>unfortunately 2 months later a reply is posted stating
>that they have now developed equivalent (but broken) code :(

To say that our code is broken is not technically correct.  We
designed our async snapshot code with a different set of priorities
based upon the desires of our target audience.  Maximum performance
was deemed more important than the integrity of the snapshot across
a system crash as long as snapshot integrity is maintained across
clean shutdowns.  The code performs as advertised and is not
broken.  What you have an issue with is the design priorities we
followed when creating this version of async snapshots (we have
another version in the works which I think you may like better).

BTW, our performance team has been trying to get LVM2/Device Mapper
to work on some benchmarks so that they can complete their performance
work comparing LVM2/device mapper snapshots against EVMS snapshots.
In the performance results that were posted to this mailing list on
Fri, 12 Jul 2002 18:21:08 by Andrew Theurer <habanero@us.ibm.com>,
you will notice several DNFs.  Here we have LVM2/Device Mapper code
which is NOT working in accordance with its design, and is therefore
a better match for the term "broken".  The point here is that
LVM2/EVMS/Device Mapper are not perfect and there is little to be
gained by throwing stones at each other.

>
>Sistina and IBM *are* both competing with their volume managers, but I
>feel that this competition should be occuring in userland - and
>certainly is not relevant to this list.  For instance EVMS appears to
>do Volume + FS management whereas LVM2 does just volume management -
>in no way does device-mapper preclude FS management, yet that is the
>impression that some of the postings to the list have been giving.
>
>- Joe


Ben Rafanello
EVMS Team Lead
IBM Linux Technology Center
(512) 838-4762
benr@us.ibm.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Steve Pratt]

on  2002-07-22 19:07:25 Christoph Hellwig wrote:

... snip

>> There
>> does not appear to be anything in either LVM2 or Device Mapper for
>> manipulating partition tables and resizing partitions.  User space tools
>> could be written to work with Device Mapper to make this happen, but
such
>> tools do not yet exist, AFAIK.

>And EVMS sucks in trucloads of fs code that already exists in userspace
>instead of using e.g. the parted library that can easily be linked to the
>LVM2 tools.

I don't know what code you are looking at because EVMS does
not suck in any code from existing fs utilities.  We only have enough
code to invoke the EXISTING utilities.  The only code we have is
simple things like version checks, superblock probes, and size
constraints.  For example, unlike  libparted which re-implements
resize of ext2 volumes, EVMS invokes the existing resize2fs.
In fact, all FSIMs have been developed in collaboration with the
filesystem owners, and in the case of JFS and EXT2/3 the FS
utility owners actually wrote the FSIM!

Also, if it is so easy to link parted with LVM2 to get greater
functionality,
why hasn't the LVM team or Andrew done this yet?  We went down this
road and found it was a dead end.

Steve

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Joe Thornber]

On Mon, Jul 22, 2002 at 04:42:19PM -0500, Steve Pratt wrote:
> Also, if it is so easy to link parted with LVM2 to get greater
> functionality,
> why hasn't the LVM team or Andrew done this yet?

Because we don't want to.  LVM is a volume manager *not* an fs
manager.  We may however release a few little shell scripts, as a
seperate package, that wrap LVM2 commands and fs commands - no more
than this is needed for your much vaunted fs functionality.

- Joe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Ben Rafanello]

On Sun, 2002-07-21 at 1:24 Alan Cox wrote:
>On Sat, 2002-07-20 at 22:24, Andreas Dilger wrote:
>> I, for one, would like to have the choice to use the AIX LVM format, and
>> I'm sure that people thinking of migrating from HP/UX or whatever would
>> want to be able to add support for their on-disk LVM format.  It really
>> provides a framework to consolidate all of the partition/MD code into
>> a single place (e.g. RAID, LVM, LDM (windows NT), DOS, BSD, Sun, etc).
>
>The LVM format for AIX and so on call all be handled by LVM2

I believe you are referring to Device Mapper, which could, in theory,
handle the AIX metadata layout.  However, AFAIK, there are no tools
currently available or under development for Device Mapper to make
this happen.  Currently, EVMS is the only way to read/write to AIX
volumes under Linux.

>
>> EVMS also allows things like creating snapshots and resizing for
>> partitions that were not originally set up as LVM volumes (i.e. you can
>> "upgrade" your existing DOS partitions in-place to support LVM features
>> instead of requiring a backup/restore cycle.
>
>LVM2 has had this for months

EVMS can snapshot anything it sees - partitions, LVM volumes, MD devices,
OS/2 volumes, AIX volumes, etc.  LVM2 does do snapshots of LVM2 volumes,
but if it isn't an LVM volume, LVM2 can not snapshot it.  Device Mapper,
however, could snapshot partitions and other non-LVM volumes if only the
tools were available.  As for resizing partitions, EVMS has the code to
manipulate partition tables, including the resizing of partitions.  There
does not appear to be anything in either LVM2 or Device Mapper for
manipulating partition tables and resizing partitions.  User space tools
could be written to work with Device Mapper to make this happen, but such
tools do not yet exist, AFAIK.


Ben Rafanello
EVMS Team Lead
IBM Linux Technology Center
(512) 838-4762
benr@us.ibm.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Christoph Hellwig]

On Mon, Jul 22, 2002 at 01:31:11PM -0500, Ben Rafanello wrote:
> I believe you are referring to Device Mapper, which could, in theory,
> handle the AIX metadata layout.  However, AFAIK, there are no tools
> currently available or under development for Device Mapper to make
> this happen. 

A few steps drom from IBM marketing to the developers:

On Fri, Feb 01, 2002 at 03:59:06PM -0600, Kevin Corry wrote:
> I have been thinking about this today and looking over some of the 
> device-mapper interfaces. I will agree that, in concept, EVMS could be 
> modified to use device-mapper for I/O remapping. However, as things stand 
> today, I don't think the transition would be easy.
> 
> As I'm trying to envision it, the EVMS runtime would become a "volume 
> recognition" framework (see tanget below). Every current EVMS plugin would 
> then probe all available devices and communicate the necessary volume 

...


> The
> does not appear to be anything in either LVM2 or Device Mapper for
> manipulating partition tables and resizing partitions.  User space tools
> could be written to work with Device Mapper to make this happen, but such
> tools do not yet exist, AFAIK.

And EVMS sucks in trucloads of fs code that already exists in userspace
instead of using e.g. the parted library that can easily be linked to the
LVM2 tools.

EVMS is not about integration but sucking in tons of code into a big IBM
project.  A little cooperation would help instead of doing everything
from scratch and ignoring existing functionality.

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Joe Thornber]

On Mon, Jul 22, 2002 at 01:31:11PM -0500, Ben Rafanello wrote:
> I believe you are referring to Device Mapper, which could, in theory,
> handle the AIX metadata layout.  However, AFAIK, there are no tools
> currently available or under development for Device Mapper to make
> this happen.  Currently, EVMS is the only way to read/write to AIX
> volumes under Linux.

This is absolutely correct, LVM2 does not currently support AIX
metadata.  However the LVM2 tools were designed to support multiple
metadata formats, and it really would be very little work to write the
code to do this (after all this is just a little bit of userland code,
rather than kernel code in EVMS).  ATM Sistina are not willing to pay
for this work, so it will have to come from some other part of the
community.

> EVMS can snapshot anything it sees - partitions, LVM volumes, MD devices,
> OS/2 volumes, AIX volumes, etc.  LVM2 does do snapshots of LVM2 volumes,
> but if it isn't an LVM volume, LVM2 can not snapshot it.  Device Mapper,
> however, could snapshot partitions and other non-LVM volumes if only the
> tools were available.

There is a little tool called dmsetup:

http://people.sistina.com/~thornber/dmsetup_8.html

that is essentially a very simple volume manager.  But it does give
you full access to all the facilities of device-mapper.  eg, I just
used it to create writeable snapshots of a CD, very useful for
demonstrating distros.  LVM2 will support physical volumes that it is
not allowed to write metadata to very soon.

>  As for resizing partitions, EVMS has the code to
> manipulate partition tables, including the resizing of partitions.  There
> does not appear to be anything in either LVM2 or Device Mapper for
> manipulating partition tables and resizing partitions.

There will never be partition manipulation code in LVM2, there are
plenty of excellent tools for resizing partitions (eg, parted).  We
have better things to do than reinventing wheels.

Personally I would remove the partition recognition code from the
kernel completely, and setup partitions from userland using
device-mapper.  You need root permissions to read a partition table,
*not* kernel perms.  But somehow I can't see people going along with
this plan :)

- Joe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > o EVMS (Enterprise Volume Management System)      (EVMS team)
> 
> or LVM2, which already appears to be scrubbed down and clean

Is there any reason why not both can go in? As far as I know neither
of them needs much of core changes, they are more like independent "drivers"
of the generic block layer stacking interface. There are already multiple
drivers of this - LVM and the various MD personalities.

One disadvantage of the LVM2 concept is that it relies a lot on compatible
user space and there is unlikely to be a stable API. While I'm normally
all for putting things in user space where it makes sense I think the
mounting of your root file system is a bit of exception. 

I used LVM1 for some brief period and managing the different incompatible
user space tools if you wanted to boot different kernels with different
incompatible user space tool versions in parallel for development was
just hell. I don't see LVM2 being much better here - as soon as you want
to run more than a single kernel version you will likely run into problems
with the user space tool versioning.

With EVMS' concept of having more stuff in kernel space (especially the
initial recovery) it looks much more likely that one can keep using it
over multiple kernel versions with minimal hazzle.
Of course LVM2 is still the much elegant design, but at least for some
use cases (like mine) I see space for EVMS.

But then they are essentially device drivers anyways. No reason why not
both can be merged. 

-Andi

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Austin Gonyou]

On Sun, 2002-07-21 at 01:57, Andi Kleen wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> > > o EVMS (Enterprise Volume Management System)      (EVMS team)
> > 
> > or LVM2, which already appears to be scrubbed down and clean
> 
> Is there any reason why not both can go in? As far as I know neither
> of them needs much of core changes, they are more like independent "drivers"
> of the generic block layer stacking interface. There are already multiple
> drivers of this - LVM and the various MD personalities.

I wholly agree. I had a couple of emails about my 2 cents..and
well..that's what it seems is the logical choice, but development time
to do such a thing seems to be the bottleneck, if there is one.

... 
> 
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Austin Gonyou <austin@digitalroadkill.net>

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Oliver Neukum]

Am Sonntag, 21. Juli 2002 08:57 schrieb Andi Kleen:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > > o EVMS (Enterprise Volume Management System)      (EVMS team)
> >
> > or LVM2, which already appears to be scrubbed down and clean
>
> Is there any reason why not both can go in? As far as I know neither
> of them needs much of core changes, they are more like independent
> "drivers" of the generic block layer stacking interface. There are
> already multiple drivers of this - LVM and the various MD personalities.

The interfaces to filesystems for things like online resizing.
If these are not compatible and stay compatible, you cause fs
developers a lot of pain.

	Regards
		Oliver

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Andi Kleen]

On Sun, Jul 21, 2002 at 10:33:59AM +0200, Oliver Neukum wrote:
> Am Sonntag, 21. Juli 2002 08:57 schrieb Andi Kleen:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > > > o EVMS (Enterprise Volume Management System)      (EVMS team)
> > >
> > > or LVM2, which already appears to be scrubbed down and clean
> >
> > Is there any reason why not both can go in? As far as I know neither
> > of them needs much of core changes, they are more like independent
> > "drivers" of the generic block layer stacking interface. There are
> > already multiple drivers of this - LVM and the various MD personalities.
> 
> The interfaces to filesystems for things like online resizing.
> If these are not compatible and stay compatible, you cause fs
> developers a lot of pain.

Both LVM and EVMS do file system resizing in user space and by calling
some file system specific modules. So the filesystem is in control.
No issue.

-Andi

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alan Cox]

On Sun, 2002-07-21 at 07:57, Andi Kleen wrote:
> One disadvantage of the LVM2 concept is that it relies a lot on compatible
> user space and there is unlikely to be a stable API. While I'm normally
> all for putting things in user space where it makes sense I think the
> mounting of your root file system is a bit of exception. 

LVM2 relies on people doing things right so we shouldnt use it ? 

Strange

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Andi Kleen]

On Sun, Jul 21, 2002 at 02:40:11PM +0100, Alan Cox wrote:
> On Sun, 2002-07-21 at 07:57, Andi Kleen wrote:
> > One disadvantage of the LVM2 concept is that it relies a lot on compatible
> > user space and there is unlikely to be a stable API. While I'm normally
> > all for putting things in user space where it makes sense I think the
> > mounting of your root file system is a bit of exception. 
> 
> LVM2 relies on people doing things right so we shouldnt use it ? 

The problem in my opinion with LVM2 is that the design makes it 
near impossible to get a stable ABI between user and kernel space
(at least if you don't want to freeze it completely). User space
and kernel space are deeply tangled together and there is no
abstraction layer

And after my LVM1 experiences I am not going to give my root filesystem
to anything that is not committed to a stable ABI between all 
stable and development kernels.

To give one example: at one point I had 
/lvmtools1/vgchange -a y || /lvmtools2/vgchange -a y || /lvmtools3/vgchange -a y
in an startup script just to handle booting of different kernel versions
with differnet incompatible LVM ABIs on the same system. 
As far as I can see this problem is not addressed in LVM2 and its design
makes it even harder to address than it was in LVM1

Then of course there are people who only ever use a single kernel
version and for them this is no issue and I guess for them LVM2 will
be fine. But for the others EVMS looks like a better alternative.

But as I said in my earlier mail there is really no reason to chose 
on over another. They do not impact any core code and both can be put in.

-Andi

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alasdair Kergon]

On Sun, Jul 21, 2002 at 04:10:50PM +0200, Andi Kleen wrote:
> The problem in my opinion with LVM2 is that the design makes it
> near impossible to get a stable ABI between user and kernel space
> (at least if you don't want to freeze it completely). 

> As far as I can see this problem is not addressed in LVM2 and its design
> makes it even harder to address than it was in LVM1

On the contrary, device-mapper (which is the name we have given to the
generic kernel driver that LVM2 uses) goes out of its way to learn
these lessons from LVM1 and to provide mechanisms so we can avoid this
sort of potential problem as new features are added etc.

Of course we hope the existing interface is reasonably stable and
changes will just be additions to support new features.  But
nevertheless LVM2/device-mapper is designed to cope with all sorts of
scenarios, including a single version of userspace tools working
sensibly with both older *and newer* versions of the kernel driver.

We have three layers:
  +------------+---------+------------+
  | LVM2 Tools | dmsetup | Other apps |  Userspace apps
  +------------+---------+------------+
  | device-mapper library             |  Userspace library
  +-----------------------------------+
  | device-mapper                     |  Kernel driver
  +-----------------------------------+

Userspace library/kernel driver interface:
  LVM1 attached a single version number to this ioctl interface,
  and a version number mismatch meant the tools would fail.

  The device-mapper ioctl interface attaches a 3-component version
  number to each individual command so we can handle fine-grained 
  forwards and/or backwards compatibility easily if we need to - and 
  in either the kernel or in the library as appropriate.

Alasdair
-- 
agk@uk.sistina.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Timothy D. Witham]

  It is more like EVMS has safety devices to prevent people from
getting caught up in the machinery.  In that respect it keeps
people from hurting themselves. And even if it is only when 
the are tired or in a hurry it is worth the effort. When you
have several 100 servers that you need to take care of any
help is appreciate.

Since most data loss is human error having a volume manager to 
enable people to have higher availability and not addressing 
the number one cause of data loss doesn't seem to make sense to 
me.

 
On Sun, 2002-07-21 at 06:40, Alan Cox wrote:
> On Sun, 2002-07-21 at 07:57, Andi Kleen wrote:
> > One disadvantage of the LVM2 concept is that it relies a lot on compatible
> > user space and there is unlikely to be a stable API. While I'm normally
> > all for putting things in user space where it makes sense I think the
> > mounting of your root file system is a bit of exception. 
> 
> LVM2 relies on people doing things right so we shouldnt use it ? 
> 
> Strange
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Timothy D. Witham - Lab Director - wookie@osdlab.org
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office)    (503)-702-2871     (cell)
(503)-626-2436     (fax)

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Tom Walcott]

On Jul 21, 2002  01:24 +0100, Alan Cox wrote:
> On Sat, 2002-07-20 at 22:24, Andreas Dilger wrote:
> > I, for one, would like to have the choice to use
the AIX LVM format, and
> > I'm sure that people thinking of migrating from
HP/UX or whatever would
> > want to be able to add support for their on-disk
LVM format.  It really
> > provides a framework to consolidate all of the
partition/MD code into
> > a single place (e.g. RAID, LVM, LDM (windows NT),
DOS, BSD, Sun, etc).
> 
> The LVM format for AIX and so on call all be handled
by LVM2

Can LVM2 currently do everything that EVMS does? From
looking at this, it appears there is a difference.
http://evms.sourceforge.net/comparison.pdf

-Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alan Cox]

On Sun, 2002-07-21 at 05:42, Tom Walcott wrote:
> Can LVM2 currently do everything that EVMS does? From
> looking at this, it appears there is a difference.
> http://evms.sourceforge.net/comparison.pdf

Include an identical comparison document by the LVM2 team and it might
be worth looking at in detail 8)

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Tom Walcott]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sun, 2002-07-21 at 05:42, Tom Walcott wrote:
> > Can LVM2 currently do everything that EVMS does?
> > From looking at this, it appears there is a >> > >
difference. > >
http://evms.sourceforge.net/comparison.pdf
> 
> Include an identical comparison document by the LVM2
> team and it might
> be worth looking at in detail 8)
> 

I have not been able to find anything from them. If
the LVM2 team has such a document, let them post it.
Otherwise, they could respond to anything they feel is
inaccurate.
 
-Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Mark Peloquin]

On Wed, 2002-07-17 at 23:49, Guillaume Boissiere wrote:
> I broke down my status list into 3 categories:
> - likely to be merged before the Halloween feature freeze
> - likely not to be ready by Halloween
> - ongoing work
>
> Do you think the breakdown is realistic?
>
> -- Guillaume

o EVMS (Enterprise Volume Management System)      (EVMS team)

We are currently working to scrub and clean the code to
be compliant with the most recent kernel coding guidelines
by Greg K.H. EVMS will be ready in early August. The EVMS
team welcomes any comments, criticism, or suggestions.

Mark

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alan Cox]

On Fri, 2002-07-19 at 15:05, Mark Peloquin wrote:
> On Wed, 2002-07-17 at 23:49, Guillaume Boissiere wrote:
> > I broke down my status list into 3 categories:
> > - likely to be merged before the Halloween feature freeze
> > - likely not to be ready by Halloween
> > - ongoing work
> >
> > Do you think the breakdown is realistic?
> >
> > -- Guillaume
> 
> o EVMS (Enterprise Volume Management System)      (EVMS team)

or LVM2, which already appears to be scrubbed down and clean

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Austin Gonyou]

On Sat, 2002-07-20 at 16:05, Alan Cox wrote:
...
> > > Do you think the breakdown is realistic?
> > >
> > > -- Guillaume
> > 
> > o EVMS (Enterprise Volume Management System)      (EVMS team)
> 
> or LVM2, which already appears to be scrubbed down and clean

Just IMHO, LVM2 makes better sense as there currently is no "stable"
module for XFS in EVMS, AFAIK.
Also, LVM is currently in 2.4 and a lot of peopel use it, LVM2 seems to
be the proper progression for 2.6. My $0.02


> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Austin Gonyou <austin@digitalroadkill.net>

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[David Weinehall]

On Sat, Jul 20, 2002 at 03:30:29PM -0500, Austin Gonyou wrote:
> On Sat, 2002-07-20 at 16:05, Alan Cox wrote:
> ...
> > > > Do you think the breakdown is realistic?
> > > >
> > > > -- Guillaume
> > > 
> > > o EVMS (Enterprise Volume Management System)      (EVMS team)
> > 
> > or LVM2, which already appears to be scrubbed down and clean
> 
> Just IMHO, LVM2 makes better sense as there currently is no "stable"
> module for XFS in EVMS, AFAIK.
> Also, LVM is currently in 2.4 and a lot of peopel use it, LVM2 seems to
> be the proper progression for 2.6. My $0.02

I'd rather see the EVMS go in, if a choice has to be made between the
two. EVMS seems to have a lot of effort put in it, and has the
experience from the (very good) volume-managers that IBM have in OS/2
and AIX.

Afaik, EVMS supports LVM volumes. As for XFS, I'm sure an XFS module can
be produced for EVMS (then again, XFS isn't merged yet either...)


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Andreas Dilger]

On Jul 20, 2002  22:55 +0200, David Weinehall wrote:
> On Sat, Jul 20, 2002 at 03:30:29PM -0500, Austin Gonyou wrote:
> > On Sat, 2002-07-20 at 16:05, Alan Cox wrote:
> > Just IMHO, LVM2 makes better sense as there currently is no "stable"
> > module for XFS in EVMS, AFAIK.
> > Also, LVM is currently in 2.4 and a lot of peopel use it, LVM2 seems to
> > be the proper progression for 2.6. My $0.02
> 
> I'd rather see the EVMS go in, if a choice has to be made between the
> two. EVMS seems to have a lot of effort put in it, and has the
> experience from the (very good) volume-managers that IBM have in OS/2
> and AIX.

I, for one, would like to have the choice to use the AIX LVM format, and
I'm sure that people thinking of migrating from HP/UX or whatever would
want to be able to add support for their on-disk LVM format.  It really
provides a framework to consolidate all of the partition/MD code into
a single place (e.g. RAID, LVM, LDM (windows NT), DOS, BSD, Sun, etc).

EVMS also allows things like creating snapshots and resizing for
partitions that were not originally set up as LVM volumes (i.e. you can
"upgrade" your existing DOS partitions in-place to support LVM features
instead of requiring a backup/restore cycle.

> Afaik, EVMS supports LVM volumes. As for XFS, I'm sure an XFS module can
> be produced for EVMS (then again, XFS isn't merged yet either...)

Even if there is no XFS FSIM module for EVMS, it doesn't mean you can't
use XFS filesystems on EVMS volumes.  The only thing it means is that you
don't get integrated volume+filesystem resize+don't shoot foot support.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alan Cox]

On Sat, 2002-07-20 at 22:24, Andreas Dilger wrote:
> I, for one, would like to have the choice to use the AIX LVM format, and
> I'm sure that people thinking of migrating from HP/UX or whatever would
> want to be able to add support for their on-disk LVM format.  It really
> provides a framework to consolidate all of the partition/MD code into
> a single place (e.g. RAID, LVM, LDM (windows NT), DOS, BSD, Sun, etc).

The LVM format for AIX and so on call all be handled by LVM2

> EVMS also allows things like creating snapshots and resizing for
> partitions that were not originally set up as LVM volumes (i.e. you can
> "upgrade" your existing DOS partitions in-place to support LVM features
> instead of requiring a backup/restore cycle.

LVM2 has had this for months

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Andreas Dilger]

On Jul 21, 2002  01:24 +0100, Alan Cox wrote:
> On Sat, 2002-07-20 at 22:24, Andreas Dilger wrote:
> > I, for one, would like to have the choice to use the AIX LVM format, and
> > I'm sure that people thinking of migrating from HP/UX or whatever would
> > want to be able to add support for their on-disk LVM format.  It really
> > provides a framework to consolidate all of the partition/MD code into
> > a single place (e.g. RAID, LVM, LDM (windows NT), DOS, BSD, Sun, etc).
> 
> The LVM format for AIX and so on call all be handled by LVM2

Can it also do mirroring and RAID?  One of the features of AIX LVM is
mirroring on a per-PE basis.  If LVM2 can do this, then great.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Heinz J . Mauelshagen]

On Sat, Jul 20, 2002 at 07:47:14PM -0600, Andreas Dilger wrote:
> On Jul 21, 2002  01:24 +0100, Alan Cox wrote:
> > On Sat, 2002-07-20 at 22:24, Andreas Dilger wrote:
> > > I, for one, would like to have the choice to use the AIX LVM format, and
> > > I'm sure that people thinking of migrating from HP/UX or whatever would
> > > want to be able to add support for their on-disk LVM format.  It really
> > > provides a framework to consolidate all of the partition/MD code into
> > > a single place (e.g. RAID, LVM, LDM (windows NT), DOS, BSD, Sun, etc).
> > 
> > The LVM format for AIX and so on call all be handled by LVM2
> 
> Can it also do mirroring and RAID?  One of the features of AIX LVM is
> mirroring on a per-PE basis.  If LVM2 can do this, then great.

We have the mirroring target in device-mapper already working to do pvmove sane
shortly. Tool support for mirroring will follow in fall. The generic design
of device-mapper keeps it completely to the tools if you like per-PE mirroring.

> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> http://sourceforge.net/projects/ext2resize/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Ernst Lehmann]

On Sat, 2002-07-20 at 22:55, David Weinehall wrote:
> On Sat, Jul 20, 2002 at 03:30:29PM -0500, Austin Gonyou wrote:
> > On Sat, 2002-07-20 at 16:05, Alan Cox wrote:
> > ...
> > > > > Do you think the breakdown is realistic?
> > > > >
> > > > > -- Guillaume
> > > > 
> > > > o EVMS (Enterprise Volume Management System)      (EVMS team)
> > > 
> > > or LVM2, which already appears to be scrubbed down and clean
> > 
> > Just IMHO, LVM2 makes better sense as there currently is no "stable"
> > module for XFS in EVMS, AFAIK.
> > Also, LVM is currently in 2.4 and a lot of peopel use it, LVM2 seems to
> > be the proper progression for 2.6. My $0.02
> 
> I'd rather see the EVMS go in, if a choice has to be made between the
> two. EVMS seems to have a lot of effort put in it, and has the
> experience from the (very good) volume-managers that IBM have in OS/2
> and AIX.
> 
> Afaik, EVMS supports LVM volumes. As for XFS, I'm sure an XFS module can
> be produced for EVMS (then again, XFS isn't merged yet either...)
> 
Hmm, the XFS-module for EVMS is only comsetic. Because you can youe XFS
on EVMS right now.

I think the best will be to move both in the kernel, and if that is too
much :)) Then choose EVMS, because it is all under one hat. LVM and Raid
Management.

So my vote is on EVMS...
> 
> Regards: David Weinehall
>   _                                                                 _
>  // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
> //  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
> \>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Bye	
	Ernst


-- 
Ernst Lehmann <lehmann@acheron.franken.de>

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Martin Knoblauch]

>> o Add XFS (A journaling filesystem from SGI) (XFS team) 
>
>
> We are going to try for this before Halloween, Internal 
> code is being cleaned up an sanitized now, external 
> changes should start getting the same treatment soon and 
> get aired in public for, hopefully short, discussion. 
>
>
>Steve 

 it would be extremely desirable to get XFS into mainstream. Just my 2 
cents.

Martin
-- 
Martin Knoblauch
MSC.software GmbH
Am Moosfeld 13
D-81829 Muenchen, Germany

e-mail: martin.knoblauch@mscsoftware.com
httw://www.mscsoftware.com

Phone: +49-89-431987-189, Fax: +49-89-431987-7189

[2.6] Most likely to be merged by Halloween... THE LIST

[Guillaume Boissiere]

I broke down my status list into 3 categories: 
- likely to be merged before the Halloween feature freeze
- likely not to be ready by Halloween
- ongoing work

Do you think the breakdown is realistic?

-- Guillaume

PS: Remember, no more than 15-20 big features get usually 
    merged in 3 months :-)


-------------------------------------------
Before feature freeze:

o New VM with reverse mappings                    (Rik van Riel)
o Add Linux Security Module (LSM)                 (LSM team)
o Rewrite of the console layer                    (James Simmons)
o New MTRR (Memory Type Range Register) driver    (Patrick Mochel)
o Add support for CPU clock/voltage scaling       (Erik Mouw, Dave Jones, Russell King, Arjan van de Ven)
o Strict address space accounting                 (Alan Cox)
o USB gadget support                              (Stuart Lynne, Greg Kroah-Hartman)
o Add hardware sensors drivers                    (lm_sensors team)
o Serial driver restructure                       (Russell King)
o Add User-Mode Linux (UML)                       (Jeff Dike)
o Direct pagecache <-> BIO disk I/O               (Andrew Morton)
o More complete NetBEUI stack                     (Arnaldo Carvalho de Melo, from Procom donated code)
o Fix device naming issues                        (Patrick Mochel, Greg Kroah-Hartman)


After feature freeze:

o Improved i2o (Intelligent Input/Ouput) layer    (Alan Cox)
o Read-Copy Update Mutual Exclusion               (Dipankar Sarma, Rusty Russell, Andrea Arcangeli, LSE Team)
o New kernel build system (kbuild 2.5)            (Keith Owens)
o PCMCIA Zoom video support                       (Alan Cox)
o Add XFS (A journaling filesystem from SGI)      (XFS team)
o New IO scheduler                                (Jens Axboe)
o Per-mountpoint read-only, union-mounts, unionfs (Al Viro)
o Asynchronous IO (aio) support                   (Ben LaHaise)
o EVMS (Enterprise Volume Management System)      (EVMS team)
o LVM (Logical Volume Manager) v2.0               (LVM team)
o Dynamic Probes                                  (Suparna Bhattacharya, dprobes team)
o Page table sharing                              (Daniel Phillips)
o ext2/ext3 online resize support                 (Andreas Dilger)
o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
o Better event logging for enterprise systems     (Larry Kessler, evlog team)
o Full compliance with IPv6                       (Alexey Kuznetzov, Jun Murai, Yoshifuji Hideaki, USAGI team)
o UMSDOS (Unix under MS-DOS) Rewrite              (Al Viro)
o Scalable Statistics Counter                     (Ravikiran Thirumalai)
o Linux Kernel Crash Dumps                        (Matt Robinson, LKCD team)
o Add support for NFS v4                          (NFS v4 team)
o ext2/ext3 large directory support: HTree index  (Daniel Phillips, Christopher Li, Ted Ts'o)
o Zerocopy NFS                                    (Hirokazu Takahashi)
o Remove the 2TB block device limit               (Peter Chubb)
o SCTP (Stream Control Transmission Protocol)     (lksctp team)
o High resolution timers                          (George Anzinger, etc.)
o Overhaul PCMCIA support                         (David Woodhouse, David Hinds)
o Reiserfs v4                                     (Reiserfs team)
o Serial ATA support                              (Andre Hedrick)
o InfiniBand support                              (InfiniBand team)
o New lightweight library (klibc)                 (Greg Kroah-Hartman)
o Replace initrd by initramfs                     (H. Peter Anvin, Al Viro)
o Add thrashing control                           (Rik van Riel)
o Remove all hardwired drivers from kernel        (Alan Cox, etc.)
o Generic parameter/command line interface        (Keith Owens)
o New mount API                                   (Al Viro)


Ongoing work:

o Fix long-held locks for low scheduling latency  (Andrew Morton, Robert Love, etc.)
o Better support of high-end NUMA machines        (NUMA team)
o Remove use of the BKL (Big Kernel Lock)         (Alan Cox, Robert Love, Neil Brown, Dave Hansen, etc.)
o Change all drivers to new driver model          (All maintainers)

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Greg KH]

On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
> o USB gadget support         (Stuart Lynne, Greg Kroah-Hartman)

Unless I start to get some help with this, or a Zarus or some other USB
gadget type device to test with, I don't think this will happen.

I do have a single volunteer, but can always use more :)

thanks,

greg k-h

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Greg KH]

On Wed, Jul 17, 2002 at 11:08:41PM -0700, Greg KH wrote:
> On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
> > o USB gadget support         (Stuart Lynne, Greg Kroah-Hartman)
> 
> Unless I start to get some help with this, or a Zarus or some other USB
> gadget type device to test with, I don't think this will happen.

Just to be a bit clearer (as it seems some people don't fully understand
this item), I need people who have Linux running WITHIN a USB gadget,
like a Zarus.  This does not include the Palm devices, which are USB
gadgets, but do not run Linux themselves.

thanks,

greg k-h

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Shane Nay]

So, Greg, you mean generic USB-Device support? instead USB-Host 
support as is in the main tree.

There is some nice work for this in the ARM-Linux kernel specific to 
the Strong-ARM chip, but I was able to adapt it to another ARM chip I 
was working on easily.  (Though not finished yet due to a bug in the 
USB-D controller h/w)  It's got the s/w to act like a ethernet device 
or a pure bit pipe.

Have you looked closely at arch/arm/mach-sa1100/usb* recently?  It's 
not far from being generalized.  The Zaurus I believe already uses 
this work to act like an ethernet USB device, and iPaq folks on 
handhelds.org have been using it for quite some time.

Thanks,
Shane Nay.

(BTW- Great to hear this is on the agenda for the mainline)

On Thursday 18 July 2002 09:14, Greg KH wrote:
> On Wed, Jul 17, 2002 at 11:08:41PM -0700, Greg KH wrote:
> > On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere 
wrote:
> > > o USB gadget support         (Stuart Lynne, Greg Kroah-Hartman)
> >
> > Unless I start to get some help with this, or a Zarus or some
> > other USB gadget type device to test with, I don't think this
> > will happen.
>
> Just to be a bit clearer (as it seems some people don't fully
> understand this item), I need people who have Linux running WITHIN
> a USB gadget, like a Zarus.  This does not include the Palm
> devices, which are USB gadgets, but do not run Linux themselves.
>
> thanks,

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Russell King]

On Sat, Jul 20, 2002 at 12:41:05AM -0700, Shane Nay wrote:
> So, Greg, you mean generic USB-Device support? instead USB-Host 
> support as is in the main tree.

Yep.  I'm going to be providing Greg with access to such a system
today (hopefully, since I'm getting rather a large number of requests
for other things people want doing today...)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Greg KH]

On Sat, Jul 20, 2002 at 12:41:05AM -0700, Shane Nay wrote:
> So, Greg, you mean generic USB-Device support? instead USB-Host 
> support as is in the main tree.

Exactly.

> There is some nice work for this in the ARM-Linux kernel specific to 
> the Strong-ARM chip, but I was able to adapt it to another ARM chip I 
> was working on easily.  (Though not finished yet due to a bug in the 
> USB-D controller h/w)  It's got the s/w to act like a ethernet device 
> or a pure bit pipe.
> 
> Have you looked closely at arch/arm/mach-sa1100/usb* recently?  It's 
> not far from being generalized.  The Zaurus I believe already uses 
> this work to act like an ethernet USB device, and iPaq folks on 
> handhelds.org have been using it for quite some time.

Yes, the arm code is nice.  But the Zarus uses the code from Lineo,
which I have merged into the main tree at:
	bk://linuxusb.bkbits.net/usbd-2.5

I really want to merge the arm and Lineo code together, so people don't
have to maintain two different trees which work on the same devices,
doing much the same thing.  That's the goal at least :)

The code also needs some serious cleanups, which is why I am asking for
help from people with one of these devices.

thanks,

greg k-h

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Dave Jones]

On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:

 > o New VM with reverse mappings                    (Rik van Riel)

Likely.

 > o Add Linux Security Module (LSM)                 (LSM team)

Unsure, depends on the LSM folks.

 > o Rewrite of the console layer                    (James Simmons)

In progress of being merged from -dj -> mainline.

 > o New MTRR (Memory Type Range Register) driver    (Patrick Mochel)

in -dj, being pushed next week when I get home.

 > o Add support for CPU clock/voltage scaling       (Erik Mouw, Dave Jones, Russell King, Arjan van de Ven)

A few last-minute niggles to work out, and this should go into mainline soon.

 > o Strict address space accounting                 (Alan Cox)

Probably a trivial merge once the more important vm changes have happened.

 > o USB gadget support                              (Stuart Lynne, Greg Kroah-Hartman)

As per Greg's comment.

 > o Add hardware sensors drivers                    (lm_sensors team)

There are a few folks doing various i2c work outside the lm_sensors
scope, which could find its way into the tree if its ready in time.
The actual sensors stuff, unknown. There were issues with some laptops,
I don't know if they got resolved ?

 > o Serial driver restructure                       (Russell King)

Hopefully ready in time.

 > o Add User-Mode Linux (UML)                       (Jeff Dike)

Ready-to-merge.

 > o Direct pagecache <-> BIO disk I/O               (Andrew Morton)

Andrew ?

 > o More complete NetBEUI stack                     (Arnaldo Carvalho de Melo, from Procom donated code)

Depending on how busy Arnaldo gets I guess. Non-critical.

 > o Fix device naming issues                        (Patrick Mochel, Greg Kroah-Hartman)

Yep. For example, how /dev/disk/ or whatever ends up working is still unclear
to myself and a few other folks.

Other items you listed in the post-freeze section that really needs
doing before the freeze imo:

 > o LVM (Logical Volume Manager) v2.0               (LVM team)

LVM1 in 2.5 is badly borken, Sistina don't want to fix it, and whilst
there is some work getting it 'mostly functional' in my tree, ongoing
development of LVM1 is counterproductive when there is a superior
solution in the wings.  All depends on whether they can pull it off
before the freeze of course.

 > o Asynchronous IO (aio) support                   (Ben LaHaise)

Again, this is likely to happen sooner rather than after the freeze.
This will break large amounts of kernel code, and having non-compilable
kernels /after/ the freeze is undesired considering we are then in the
'get things stable' zone.
 
 > After feature freeze:

Quite a few of these you listed either should wait until 2.7 or
get in before the freeze.  Some of them require non-trivial changes
to critical areas which we really shouldn't be poking too much in
an alleged 'stabilisation series'.

Instead I would rename this section 'non critical features' or
'nice to have' features. If they don't make it in time, there's
always 2.7

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Stephen Lord]

On Wed, 2002-07-17 at 23:49, Guillaume Boissiere wrote:
> I broke down my status list into 3 categories: 
> - likely to be merged before the Halloween feature freeze
> - likely not to be ready by Halloween
> - ongoing work
> 
> Do you think the breakdown is realistic?
> 
> -- Guillaume

May as well make this one more widely known:

> o Add XFS (A journaling filesystem from SGI)      (XFS team)

We are going to try for this before Halloween, Internal
code is being cleaned up an sanitized now, external
changes should start getting the same treatment soon and
get aired in public for, hopefully short, discussion.

Steve

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Tomas Szepe]

> After feature freeze:
>
> o New kernel build system (kbuild 2.5)            (Keith Owens)

Kai, what are your intentions w/ kbuild 2.5?

I hope I'm not speaking just for myself when I say I feel it'd be
a great pity if it weren't merged.

T.

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Martin J. Bligh]

> Do you think the breakdown is realistic?

Here's a list of other things I am hoping to see merged:

shared pagetables
large page support
NUMA aware multipath IO
NUMA aware scheduler extensions
ia32 discontigmem support for NUMA machines
NUMA aware slab allocator
CONFIG_NONLINEAR (in some form, quite possibly a cut down version)
shared pagetables
large page support
rcu rtcache
rcu dcache

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Anton Blanchard]

 
> shared pagetables
> large page support

Im not sure the complexity of shared pagetables is worth it. On ppc64
it will be a real pain to support since we rely on a 1:1 mapping between
linux and ppc64 ptes.

Unless its a large gain over using large pages (I doubt that will be the
case on sane chips with large TLBs) or conditional per architecture then
I think we should avoid it.

I do think we should get large page support in ASAP.

Anton

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Hubertus Franke]

On Thursday 18 July 2002 10:31 am, Martin J. Bligh wrote:
> > Do you think the breakdown is realistic?
>
> Here's a list of other things I am hoping to see merged:
>
> shared pagetables
> large page support
> NUMA aware multipath IO
> NUMA aware scheduler extensions
> ia32 discontigmem support for NUMA machines
> NUMA aware slab allocator
> CONFIG_NONLINEAR (in some form, quite possibly a cut down version)
> shared pagetables
> large page support
> rcu rtcache
> rcu dcache
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Thanks Martin.

I am confident that we will have large page support in 2.5 by then ready and 
tested as described at OLS.

-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Greg KH]

On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
> o Add Linux Security Module (LSM)                 (LSM team)

This is starting to get presented for merging right now (see my previous
posts to lkml for an example.)

thanks,

greg k-h

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Greg KH]

On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
> o Replace initrd by initramfs                     (H. Peter Anvin, Al Viro)

A few of the features above, need this feature, so I would move it up to
"before feature freeze".  Well I hope it happens, that way we can
actually get most of the above done :)

And there are patches available for this on Al Viro's site, but I don't
know the current state of them.

thanks,

greg k-h

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Robert Love]

On Wed, 2002-07-17 at 21:49, Guillaume Boissiere wrote:

> o Strict address space accounting                 (Alan Cox)

My patch for this, while a bit large, is simple enough it can be merged
after the freeze.  E.g., if rmap is merged this is just "more rmap work"
and sane.

I would bump this down to "After feature freeze..." although I see no
reason it cannot go in sooner (I just do not consider it a pre-freeze
item in terms of its impact).

> After feature freeze:

Easily 90% of this stuff should _not_ go in after the freeze.  It either
needs to make it in now or hold its breath until 2.7.

I would much prefer a rush of merges now and less "improper" merges
after the freeze.  In fact, I do not care much what we do now as long as
we treat the freeze as a freeze and work solely to stabilize stuff.

	Robert Love

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Rik van Riel]

On 18 Jul 2002, Robert Love wrote:

> > After feature freeze:
>
> Easily 90% of this stuff should _not_ go in after the freeze.  It either
> needs to make it in now or hold its breath until 2.7.
>
> I would much prefer a rush of merges now and less "improper" merges
> after the freeze.  In fact, I do not care much what we do now as long as
> we treat the freeze as a freeze and work solely to stabilize stuff.

Agreed. What we need is a 2.6 that is relatively easy to
stabilise, not one that'll take until 2.6.20 to become
stable.

If some of the other features turn out to be needed, they
can always be backported from 2.7.  In fact, backporting
from 2.7 is probably _quicker_ than throwing in too many
features just before the feature freeze and then try to
stabilise them all at once together...

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Bill Davidsen]

On Thu, 18 Jul 2002, Guillaume Boissiere wrote:

> I broke down my status list into 3 categories: 
> - likely to be merged before the Halloween feature freeze
> - likely not to be ready by Halloween
> - ongoing work

Before I start asking what about XXX, is there a list of what major stuff
is already considered to be in? I don't see some things on your list,
perhaps you regard them as done.

> After feature freeze:

I really hope these do get in!
 
> o New kernel build system (kbuild 2.5)            (Keith Owens)
	I fear Keith might go SPC if this had to wait for 2.7
> o Add XFS (A journaling filesystem from SGI)      (XFS team)
> o Asynchronous IO (aio) support                   (Ben LaHaise)
> o LVM (Logical Volume Manager) v2.0               (LVM team)
	I thought these were all progressing nicely
> o Page table sharing                              (Daniel Phillips)
> o ext2/ext3 online resize support                 (Andreas Dilger)
	Definitely want to stabilize these
> o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
	Hopefully this is close as well
> o Full compliance with IPv6                       (Alexey Kuznetzov, Jun Murai, Yoshifuji Hideaki, USAGI team)
	could ease in 2.6.x if not?
> o Add support for NFS v4                          (NFS v4 team)
	This really shouldn't wait for 2.8!
> o Remove the 2TB block device limit               (Peter Chubb)
	This would help db folks now, and who knows how big
	a single drive will be before 2.7?
> o Overhaul PCMCIA support                         (David Woodhouse, David Hinds)
	Sure would be nice if it worked on desktops as well as laptops
> o Add thrashing control                           (Rik van Riel)

I sure would like to see documentation improvements on this list! For 2.6
it would be beautiful is no features went into /proc/sys unless they went
into the Documentation directory as well.	

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Dave Jones]

On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:

 > > o New kernel build system (kbuild 2.5)            (Keith Owens)
 > 	I fear Keith might go SPC if this had to wait for 2.7

Bit by bit, either parts of Keith's work, or orthogonal ideas
are making it in. Whether the big chunks make it by halloween remains
to be seen.

 > > o Add XFS (A journaling filesystem from SGI)      (XFS team)
 > > o Asynchronous IO (aio) support                   (Ben LaHaise)
 > > o LVM (Logical Volume Manager) v2.0               (LVM team)
 > 	I thought these were all progressing nicely

All are aiming for halloween, but none (afaik) have put forward
anything that can be merged yet. The XFS & LVM folks are still
cleaning bits and getting things presentable, whilst Ben is still
at work with aio I guess (judging by his relative silence since
the summit 8-)

 > > o Page table sharing                              (Daniel Phillips)
 > > o ext2/ext3 online resize support                 (Andreas Dilger)
 > 	Definitely want to stabilize these

"would be nice".

 > > o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
 > 	Hopefully this is close as well

This has been around for an age, but I haven't seen anything for 2.5
yet. Then again, I dropped off the packet-writing mailing list a long
time ago, so I'm not sure how up to date those folks are.

 > > o Full compliance with IPv6                       (Alexey Kuznetzov, Jun Murai, Yoshifuji Hideaki, USAGI team)
 > 	could ease in 2.6.x if not?

Davem's call I guess. ISTR the USAGI work was a rather large patch which
if in Davem's shoes, I'd be rather dubious about taking 'all-in-one'.

 > > o Add support for NFS v4                          (NFS v4 team)
 > 	This really shouldn't wait for 2.8!

Last I saw of this patch it was still against something like 2.4.1,
so they have a lot of catch up to do. This fact asides, if it doesn't
touch common code, there's no reason it can't go in post-feature freeze
in the same way as a driver/additional fs. Depends how much it touches.
That said, are there really that many NFSv4 hosts out there that make
this a *must have* feature ? Are any other *nix vendors shipping NFSv4 yet?

 > > o Remove the 2TB block device limit               (Peter Chubb)
 > 	This would help db folks now, and who knows how big
 > 	a single drive will be before 2.7?

Agreed, a pretty important feature.

 > > o Overhaul PCMCIA support                         (David Woodhouse, David Hinds)
 > 	Sure would be nice if it worked on desktops as well as laptops

"works for me". Admittedly I've not played with pcmcia much, but it
seems at least if you choose the right hardware it works fine.

 > > o Add thrashing control                           (Rik van Riel)
 > I sure would like to see documentation improvements on this list! For 2.6
 > it would be beautiful is no features went into /proc/sys unless they went
 > into the Documentation directory as well.	

ObRelated: There was some shouting about a sysctlfs at some point
which could clean up a lot of the crap in /proc/sys at the expense of
an extra mount. Al ?

        Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Thunder from the hill]

Hi,

On Thu, 18 Jul 2002, Dave Jones wrote:
> Bit by bit, either parts of Keith's work, or orthogonal ideas
> are making it in. Whether the big chunks make it by halloween remains
> to be seen.

Well, I still see unnecessary recompiles. There's a lot of stuff to do 
here, I think, which was already done in kbuild-2.5.

> Are any other *nix vendors shipping NFSv4 yet?

Seemingly. On Hawkeye, I sometimes get warnings of that kind (svc: 
unknown version (4)). However, I can't tell what kind of system the 
clients were. I've also heard about this warning from Potsdam and 
Frankfurt.

> Agreed, a pretty important feature.

I ack here, our arrays are mostly filled up with only some ten gigabytes 
left.

							Regards,
							Thunder
-- 
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o?  K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y- 
------END GEEK CODE BLOCK------

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Peter Osterlund]

Dave Jones <davej@suse.de> writes:

> On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:
> 
>  > > o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
>  > 	Hopefully this is close as well
> 
> This has been around for an age, but I haven't seen anything for 2.5
> yet. Then again, I dropped off the packet-writing mailing list a long
> time ago, so I'm not sure how up to date those folks are.

Patches for 2.5 can be found here:

        http://w1.894.telia.com/~u89404340/patches/packet/2.5/

The most recent patch is for 2.5.25. As far as I know, there are only
two remaining problems with the 2.5 patch:

1. Some drives require a "synchronize cache" command to be inserted
   before a read command if the previous command was a write. This is
   implemented in the 2.4 patch in a rather ugly way, but not in 2.5.

2. The 2.5 version uses "bio" objects instead of buffer_heads, so the
   2.4 functionality to fill in missing parts of packets with data
   from the buffer cache doesn't work. This affects performance but
   not correctness.

Jens thinks the cache sync commands should be handled at the level
below the packet writing module, in ide-cd.c and sr.c. I agree, but
haven't implemented it simply because I haven't figured out how to do
it yet.

Regarding the use of cached data for partial packets, Jens suggested
using the page cache instead of the buffer cache. I haven't figured
out how to do this either.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Peter Osterlund]

Peter Osterlund <petero2@telia.com> writes:

> Dave Jones <davej@suse.de> writes:
> 
> > On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:
> > 
> >  > > o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
> >  > 	Hopefully this is close as well
> > 
> > This has been around for an age, but I haven't seen anything for 2.5
> > yet. Then again, I dropped off the packet-writing mailing list a long
> > time ago, so I'm not sure how up to date those folks are.
> 
> Patches for 2.5 can be found here:
> 
>         http://w1.894.telia.com/~u89404340/patches/packet/2.5/
> 
> The most recent patch is for 2.5.25. As far as I know, there are only
> two remaining problems with the 2.5 patch:

Btw, there is one more potential problem. A new block major number is
allocated for the pktcdvd device. Is this still forbidden? Are there
better ways to do this now?

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Jens Axboe]

On Fri, Jul 19 2002, Peter Osterlund wrote:
> Peter Osterlund <petero2@telia.com> writes:
> 
> > Dave Jones <davej@suse.de> writes:
> > 
> > > On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:
> > > 
> > >  > > o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
> > >  > 	Hopefully this is close as well
> > > 
> > > This has been around for an age, but I haven't seen anything for 2.5
> > > yet. Then again, I dropped off the packet-writing mailing list a long
> > > time ago, so I'm not sure how up to date those folks are.
> > 
> > Patches for 2.5 can be found here:
> > 
> >         http://w1.894.telia.com/~u89404340/patches/packet/2.5/
> > 
> > The most recent patch is for 2.5.25. As far as I know, there are only
> > two remaining problems with the 2.5 patch:
> 
> Btw, there is one more potential problem. A new block major number is
> allocated for the pktcdvd device. Is this still forbidden? Are there
> better ways to do this now?

Why a new number? What's wrong with the official 97?

-- 
Jens Axboe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Peter Osterlund]

On Tue, 23 Jul 2002, Jens Axboe wrote:

> On Fri, Jul 19 2002, Peter Osterlund wrote:
> > Peter Osterlund <petero2@telia.com> writes:
> > 
> > > Dave Jones <davej@suse.de> writes:
> > > 
> > > > On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:
> > > > 
> > > >  > > o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
> > > >  > 	Hopefully this is close as well
> > > > 
> > > > This has been around for an age, but I haven't seen anything for 2.5
> > > > yet. Then again, I dropped off the packet-writing mailing list a long
> > > > time ago, so I'm not sure how up to date those folks are.
> > > 
> > > Patches for 2.5 can be found here:
> > > 
> > >         http://w1.894.telia.com/~u89404340/patches/packet/2.5/
> > > 
> > > The most recent patch is for 2.5.25. As far as I know, there are only
> > > two remaining problems with the 2.5 patch:
> > 
> > Btw, there is one more potential problem. A new block major number is
> > allocated for the pktcdvd device. Is this still forbidden? Are there
> > better ways to do this now?
> 
> Why a new number? What's wrong with the official 97?

It is still using 97. I didn't know it was official until it got into the
kernel tree. I think Linus once said he wouldn't accept patches adding
device numbers, because he wanted people to think up something better than
device numbers.

I was thinking about this old message:

	http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/1042.html

If that's no longer a problem, then fine.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Jens Axboe]

On Tue, Jul 23 2002, Peter Osterlund wrote:
> On Tue, 23 Jul 2002, Jens Axboe wrote:
> 
> > On Fri, Jul 19 2002, Peter Osterlund wrote:
> > > Peter Osterlund <petero2@telia.com> writes:
> > > 
> > > > Dave Jones <davej@suse.de> writes:
> > > > 
> > > > > On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:
> > > > > 
> > > > >  > > o UDF Write support for CD-R/RW (packet writing)  (Jens Axboe, Peter Osterlund)
> > > > >  > 	Hopefully this is close as well
> > > > > 
> > > > > This has been around for an age, but I haven't seen anything for 2.5
> > > > > yet. Then again, I dropped off the packet-writing mailing list a long
> > > > > time ago, so I'm not sure how up to date those folks are.
> > > > 
> > > > Patches for 2.5 can be found here:
> > > > 
> > > >         http://w1.894.telia.com/~u89404340/patches/packet/2.5/
> > > > 
> > > > The most recent patch is for 2.5.25. As far as I know, there are only
> > > > two remaining problems with the 2.5 patch:
> > > 
> > > Btw, there is one more potential problem. A new block major number is
> > > allocated for the pktcdvd device. Is this still forbidden? Are there
> > > better ways to do this now?
> > 
> > Why a new number? What's wrong with the official 97?
> 
> It is still using 97. I didn't know it was official until it got into the
> kernel tree. I think Linus once said he wouldn't accept patches adding
> device numbers, because he wanted people to think up something better than
> device numbers.
> 
> I was thinking about this old message:
> 
> 	http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/1042.html
> 
> If that's no longer a problem, then fine.

97 was allocated a loong time ago, it predates the above message.

-- 
Jens Axboe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Miles Lane]

On Thu, 2002-07-18 at 16:22, Dave Jones wrote:

>  > > o Overhaul PCMCIA support                         (David Woodhouse, David Hinds)
>  > 	Sure would be nice if it worked on desktops as well as laptops
> 
> "works for me". Admittedly I've not played with pcmcia much, but it
> seems at least if you choose the right hardware it works fine.

Uh, I have seen no patches from David for this?  Have I somehow
missed this?  

I would dearly love to see this functionality get added.  I would 
also like to hear what the implementation plan is.  Will the 
need for /etc/pcmcia go away?  Will the new code do a better job
of knowing what drivers to load without system configuration files?
How will device removal be handled?  Will we still need cardctl
and cardmgr?  

I just went through a process yesterday of trying to get some
PCMCIA wireless PC Card configuration.  It isn't at all straightforward,
even with pcmcia-cs.

	Miles

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Bill Davidsen]

On Thu, 18 Jul 2002, Dave Jones wrote:

> On Thu, Jul 18, 2002 at 12:46:43PM -0400, Bill Davidsen wrote:

>  > > o Full compliance with IPv6                       (Alexey Kuznetzov, Jun Murai, Yoshifuji Hideaki, USAGI team)
>  > 	could ease in 2.6.x if not?
> 
> Davem's call I guess. ISTR the USAGI work was a rather large patch which
> if in Davem's shoes, I'd be rather dubious about taking 'all-in-one'.

Before the freeze it should be fine, after all if working IDE is optional
in a development kernel IPV6 is certainly not a must-have (unless it
seriously break IPV4, obviously).
 
>  > > o Add support for NFS v4                          (NFS v4 team)
>  > 	This really shouldn't wait for 2.8!
> 
> Last I saw of this patch it was still against something like 2.4.1,
> so they have a lot of catch up to do. This fact asides, if it doesn't
> touch common code, there's no reason it can't go in post-feature freeze
> in the same way as a driver/additional fs. Depends how much it touches.
> That said, are there really that many NFSv4 hosts out there that make
> this a *must have* feature ? Are any other *nix vendors shipping NFSv4 yet?

Not that I have used, this was more of a preemptive effort to get it in
2.6 rather than 2.8, since most vendors will be shipping in less than a
year if you believe their unofficial comments. And if the benefits are
there it would be a good thing to have first, perhaps.

>  > > o Overhaul PCMCIA support                         (David Woodhouse, David Hinds)
>  > 	Sure would be nice if it worked on desktops as well as laptops
> 
> "works for me". Admittedly I've not played with pcmcia much, but it
> seems at least if you choose the right hardware it works fine.

I haven't had it work since about 2.6 on a BP6 with an adaptor, but it did
work in 2.4.early. Of course it could be related to the new IDE stuff
making compact flash fail, but even building a uni kernel doesn't help. I
bought a cheap used laptop just to use as a card reader, but I'd rather
not stay that way ;-) Guess for now that's the "right hardware."

Thanks for all the additional feedback.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Guillaume Boissiere]

> Before I start asking what about XXX, is there a list of what major stuff
> is already considered to be in? I don't see some things on your list,
> perhaps you regard them as done.

The list you are looking for is all the items in the merged category in the
status list: http://www.kernelnewbies.org/status/

Several of the items marked merged are still being worked on (IDE, etc.), 
but for those, the bulk of the work should have been done already.

Cheers,

-- Guillaume

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[William Lee Irwin III]

On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
> Ongoing work:

My projects:

(1) parallelizing pagefaults
(2) parallelizing page replacement
(3) allocating pte_chains from highmem
(4) deferred coalescing page allocation
(5) removing embedding waitqueue heads / hashing all waitqueues
(6) removing the global tasklist and all iterations over it



Cheers,
Bill

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Joe Thornber]

On Thu, Jul 18, 2002 at 12:49:21AM -0400, Guillaume Boissiere wrote:
> o EVMS (Enterprise Volume Management System)      (EVMS team)
> o LVM (Logical Volume Manager) v2.0               (LVM team)

Some comments on the 'EVMS vs LVM2' threads:

I am only petitioning for the driver called 'device-mapper' to be
included in the kernel.  This is a *much* lower level volume manager
than either the EVMS or LVM1 drivers.  I am *not* petitioning for EVMS
not to be included.

People are getting understandably confused between device-mapper and
LVM2:

*) device-mapper is a driver, intended to provide an extensible (via
   the definition of new targets) framework capable of support
   *anything* that volume management applications should want to do.

*) LVM2 is a userland application that uses the device-mapper driver to
   provide a set of tools very similar to LVM1.  Currently LVM2 is the
   only userland application that uses this driver, leading people to
   associate the two far too strongly.

It would be good if other volume managers embrace device-mapper
allowing us to work together on the kernel side, and compete in
userland.  Kernel development takes *far* too much manpower for us to
be duplicating work.  For example I released the LVM2 vs EVMS snapshot
benchmarks in the hope of encouraging EVMS to move over to
device-mapper, unfortunately 2 months later a reply is posted stating
that they have now developed equivalent (but broken) code :(

Sistina and IBM *are* both competing with their volume managers, but I
feel that this competition should be occuring in userland - and
certainly is not relevant to this list.  For instance EVMS appears to
do Volume + FS management whereas LVM2 does just volume management -
in no way does device-mapper preclude FS management, yet that is the
impression that some of the postings to the list have been giving.

- Joe

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Daniel Phillips]

On Monday 22 July 2002 12:23, Joe Thornber wrote:
> It would be good if other volume managers embrace device-mapper
> allowing us to work together on the kernel side, and compete in
> userland.  Kernel development takes *far* too much manpower for us to
> be duplicating work.

Competition has its own benefits.

> For example I released the LVM2 vs EVMS snapshot
> benchmarks in the hope of encouraging EVMS to move over to
> device-mapper, unfortunately 2 months later a reply is posted stating
> that they have now developed equivalent (but broken) code :(

Supposing both device-mapper and (the kernel part of) EVMS get into the tree, 
there's nothing stopping you from submitting a patch to make EVMS use 
device-mapper.  If there's already equivalent code in EVMS, that just makes 
the job easier.

I'm firmly in the 'we need both' camp.

EVMS is a full-bloated^W blown enterprise solution, ready to go with every
imaginable bell and whistle.  Device-mapper represents the classic Linux 
minimalist approach.  Hopefully, with the two side-by-side in the tree, both 
will evolve more rapidly.

-- 
Daniel

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alan Cox]

On Mon, 2002-07-22 at 16:22, Daniel Phillips wrote:developed equivalent
> Supposing both device-mapper and (the kernel part of) EVMS get into the tree, 
> there's nothing stopping you from submitting a patch to make EVMS use 
> device-mapper.  If there's already equivalent code in EVMS, that just makes 
> the job easier.

So we end up with twice as much code to debug and lots of
incompatibilities when people want to switch around. It would be far
better if the two sets of userspace code could at least agree on a
common kernel interface

> I'm firmly in the 'we need both' camp.

If there is something important in only one then that matters. If there
are important features in each that are not in the other then that
really proves they should merge the projects

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Daniel Phillips]

On Monday 22 July 2002 18:57, Alan Cox wrote:
> On Mon, 2002-07-22 at 16:22, Daniel Phillips wrote:developed equivalent
> > Supposing both device-mapper and (the kernel part of) EVMS get into the tree, 
> > there's nothing stopping you from submitting a patch to make EVMS use 
> > device-mapper.  If there's already equivalent code in EVMS, that just makes 
> > the job easier.
> 
> So we end up with twice as much code to debug and lots of
> incompatibilities when people want to switch around.

If that were a problem, Linux would only have one filesystem.

> It would be far
> better if the two sets of userspace code could at least agree on a
> common kernel interface

Oh, absolutely.

> > I'm firmly in the 'we need both' camp.
> 
> If there is something important in only one then that matters. If there
> are important features in each that are not in the other then that
> really proves they should merge the projects

I dunno about that.  There's more of interest in a subsystem than just what
features it has.  Relying only on what I've seen in this thread, it would
seem natural for EVMS to depend on device-mapper - but why is it necessary
to force the issue immediately, beyond hashing out a suitable interface?

-- 
Daniel

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alan Cox]

On Mon, 2002-07-22 at 17:45, Daniel Phillips wrote:
> > So we end up with twice as much code to debug and lots of
> > incompatibilities when people want to switch around.
> 
> If that were a problem, Linux would only have one filesystem.

The device mapper functionality is generic. We only have one VFS, we
only need one mapping layer. What cool stuff people build on top of the
mapping layer is another matter. If the mapping layer supports all of
the requirements its done right, if not its borked and wants fixing
first.

Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Bill Davidsen]

On Mon, 22 Jul 2002, Daniel Phillips wrote:

> On Monday 22 July 2002 12:23, Joe Thornber wrote:

> > For example I released the LVM2 vs EVMS snapshot
> > benchmarks in the hope of encouraging EVMS to move over to
> > device-mapper, unfortunately 2 months later a reply is posted stating
> > that they have now developed equivalent (but broken) code :(
> 
> Supposing both device-mapper and (the kernel part of) EVMS get into the tree, 
> there's nothing stopping you from submitting a patch to make EVMS use 
> device-mapper.  If there's already equivalent code in EVMS, that just makes 
> the job easier.
> 
> I'm firmly in the 'we need both' camp.
> 
> EVMS is a full-bloated^W blown enterprise solution, ready to go with every
> imaginable bell and whistle.  Device-mapper represents the classic Linux 
> minimalist approach.  Hopefully, with the two side-by-side in the tree, both 
> will evolve more rapidly.

Based on reading this thread and some articles referenced and searched, it
would appear that EVMS and LVM2 could/should use the same underpining,
such as device-mapper. If you have two competing planes they should still
land on the same runway. That way other software could be written which
did still other things, or the same things in different ways. Having two
kinds of lowest level under them seems like more code to maintain than is
necessary, and may lead to conflicts if both are in use. I know the EVMS
folks say that won't happen, and there's a good reason for having two
groups inventing the wheel, but I'd feel better if ther was one wheel and
a single API which all *VM* software could use.

I suspect that there's som NIH involved...

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.