LinuxLists.cc - EVMS Submission for 2.5

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wed, 2 Oct 2002, Kevin Corry wrote:

> On behalf of the EVMS team, I'd like to submit the Enterprise Volume
> Management System for inclusion in the 2.5 Linux kernel tree.
>
> To make this as simple as possible for you, there is a Bitkeeper
> tree available with the latest EVMS source code, located at:
> http://evms.bkbits.net/linux-2.5
> This tree is sync'd with the linux-2.5 tree on linux.bkbits.net
> as of about noon today (Oct 2).

> - Add a function, walk_gendisk(), to drivers/block/genhd.c to allow
> EVMS to get information about the disks on the system from the
> gendisk list in a safe manner.

Consider that one vetoed. Linus, please do _not_ apply until that
stuff is resolved - it conflicts with a bunch of cleanups we'll
need.

2002-10-02 22:30:32

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wednesday 02 October 2002 17:14, Alexander Viro wrote:
> On Wed, 2 Oct 2002, Kevin Corry wrote:
> > On behalf of the EVMS team, I'd like to submit the Enterprise Volume
> > Management System for inclusion in the 2.5 Linux kernel tree.
> >
> > To make this as simple as possible for you, there is a Bitkeeper
> > tree available with the latest EVMS source code, located at:
> > http://evms.bkbits.net/linux-2.5
> > This tree is sync'd with the linux-2.5 tree on linux.bkbits.net
> > as of about noon today (Oct 2).
> >
> > - Add a function, walk_gendisk(), to drivers/block/genhd.c to allow
> > EVMS to get information about the disks on the system from the
> > gendisk list in a safe manner.
>
> Consider that one vetoed. Linus, please do _not_ apply until that
> stuff is resolved - it conflicts with a bunch of cleanups we'll
> need.

Yeah, I figured you wouldn't like that part, especially based on your
discussion with Mark yesterday about the upcoming gendisk changes.

EVMS has traditionally used the gendisk list to get information about what
disks are available in the system. The walk_gendisk() function in genhd.c was
suggested last year by Christoph as a method for safely accessing the list,
and even made it into the 2.4 kernel. Thus we just ported it forward to 2.5
in our tree. It worked just fine in its original form until 2.5.40. Based on
your comments in genhd.c about the gendisks array, I assumed further changes
would be coming. But we had to come up with an interim solution to work on
2.5.40, and thus we have the version in the submitted patch, which I did not
intend to be a permanent solution.

So the question is, will there be a method to simply get a list of registered
disks on the system, or an API to call to run a function for each disk? If
so, we'll gladly switch to using that. If not, do you have any suggestions
for how this kind of functionality can be achieved with your upcoming changes?

--
Kevin Corry
[email protected]
http://evms.sourceforge.net/

2002-10-02 22:40:53

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wed, Oct 02, 2002 at 04:33:20PM -0500, Kevin Corry wrote:
>
> Thank you very much for taking the time to consider this
> submission. If you have any questions or comments, please email
> us at any time. We will be happy to do whatever is necessary to
> make EVMS acceptable for inclusion in the 2.5 tree.

Some comments on the code:
- you might want to post a patch with the whole evms portion of
the code, for those people without BitKeeper to see.
- The #ifdef EVMS_DEBUG lines are still in AIXlvm_vge.c, I
thought you said you were going to fix this file up?
- The OS2 and S390 files don't look like they have been fixed,
like you said you would before submission.
- evms_ecr.h and evms_linear.h have a lot of unneeded typedefs.
- the md code duplication has not been addressed, as you said it
would be.
- the BK repository contains a _lot_ of past history and merges
that are probably unnecessary to have. A few, small
changesets are nicer to look at :)

Why don't you propose a small evms patch that adds the core
functionality, and worry about getting all of the plugins and other
assorted stuff in later? You will probably get more constructive
comments, as wading through a patch 37956 lines long is a bit difficult.

thanks,

greg k-h

2002-10-02 22:57:36

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wed, 2 Oct 2002, Kevin Corry wrote:

> So the question is, will there be a method to simply get a list of registered
> disks on the system, or an API to call to run a function for each disk? If
> so, we'll gladly switch to using that. If not, do you have any suggestions
> for how this kind of functionality can be achieved with your upcoming changes?

That _really_ depends on the nature of functions you want to call that
way.

I might agree with something along the lines of
* when evms is initialized, it's notified of all existing gendisks
* whenever disk is added after evms initialization, we notify evms
* whenever disk is removed, we notify evms

However, I doubt that it's what you really want. In particular, you
probably want to see partitioning changes as well as gendisk ones
(and no, "evms will handle all partitioning" is _not_ an acceptable
answer). Moreover, "gendisk is here" != "something is in the drive".

IOW, the real question is what are you going to do with that list of
gendisks?

2002-10-03 12:40:31

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wednesday 02 October 2002 17:43, Greg KH wrote:
> Some comments on the code:
> - you might want to post a patch with the whole evms portion of
> the code, for those people without BitKeeper to see.
> - The #ifdef EVMS_DEBUG lines are still in AIXlvm_vge.c, I
> thought you said you were going to fix this file up?
> - The OS2 and S390 files don't look like they have been fixed,
> like you said you would before submission.

I have been working on these, and should have them done very soon. At the
very least, I expect to get OS2 done today. I will let you know as soon as it
is ready.

> - evms_ecr.h and evms_linear.h have a lot of unneeded typedefs.

For the time being, I have removed these files from the tree. As I mentioned
the other day, they are a long way from providing any useful clustering
functionality.

> - the md code duplication has not been addressed, as you said it
> would be.

We will be addressing this. Unfortunately, I don't see this as being a
simple, overnight fix. Finding a way to consolidate the common code may take
some time.

> - the BK repository contains a _lot_ of past history and merges
> that are probably unnecessary to have. A few, small
> changesets are nicer to look at :)

No offense meant, Greg, but that seems a bit contradictory. The way I see it,
I can maintain our Bitkeeper tree in one of two ways.

1) Try to mirror the usage of our CVS tree. This means that each file or
small group of files that gets checked into CVS also gets checked into
Bitkeeper, and the comment logs can stay closely in sync. Doing this produces
a _lot_ of _small_ changesets, but each one is fairly easy to read and
understand. However, as you mentioned, it does produce a very long history.

2) Just do a periodic sync with the current CVS tree, maybe every three days
or so. This will obviously produce far less history, but each changeset may
be quite large, and thus harder to read and understand, especially since the
comments will likely be something along the lines of "sync'ing with CVS".

> Why don't you propose a small evms patch that adds the core
> functionality, and worry about getting all of the plugins and other
> assorted stuff in later? You will probably get more constructive
> comments, as wading through a patch 37956 lines long is a bit difficult.

This is fine with me. I've been maintaining our Bitkeeper tree because I've
been told by numerous people that it is the easiest way to get new code
accepted into the kernel. If it turns out that this isn't actually the best
approach, I'll be more than happy to just send patches. Dual-maintaining CVS
and Bitkeeper trees is certainly no small task.

So, I will send in a few patches that introduce just the core code so
everyone can get a good look. There will be four files coming: evms.c,
evms.h, evms_ioctl.h, and evms_biosplit.h.

--
Kevin Corry
[email protected]
http://evms.sourceforge.net/

2002-10-03 13:32:05

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wednesday 02 October 2002 18:02, Alexander Viro wrote:
> On Wed, 2 Oct 2002, Kevin Corry wrote:
> > So the question is, will there be a method to simply get a list of
> > registered disks on the system, or an API to call to run a function for
> > each disk? If so, we'll gladly switch to using that. If not, do you have
> > any suggestions for how this kind of functionality can be achieved with
> > your upcoming changes?
>
> That _really_ depends on the nature of functions you want to call that
> way.
>
> I might agree with something along the lines of
> * when evms is initialized, it's notified of all existing gendisks
> * whenever disk is added after evms initialization, we notify evms
> * whenever disk is removed, we notify evms

This sounds like it would be exactly what EVMS needs. The only thing we would
want to add to this list is: "*whenever a disk is modified, notify evms". For
example, with removable media drives (such as Zip and Jaz), when a cartidge
is changed, the capacity of the drive might change, and we would like to be
notified of that event.

> However, I doubt that it's what you really want. In particular, you
> probably want to see partitioning changes as well as gendisk ones
> (and no, "evms will handle all partitioning" is _not_ an acceptable
> answer).

EVMS won't really be interested in partitioning changes. It only cares about
whole devices, i.e. minor_shift == 0.

> Moreover, "gendisk is here" != "something is in the drive".

Will there be a common method for determining "media present"? The current
method EVMS uses to determine "media changes" is somewhat inconsistent
between IDE and SCSI.

> IOW, the real question is what are you going to do with that list of
> gendisks?

EVMS will try to read volume metadata from each device and activate volumes
if it finds any pertinent metadata.

--
Kevin Corry
[email protected]
http://evms.sourceforge.net/

2002-10-03 14:28:32

by Christoph Hellwig

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wed, Oct 02, 2002 at 04:33:20PM -0500, Kevin Corry wrote:
> EVMS provides a new, stand-alone subsystem to the kernel

i.e. it duplictes existing block layer/volume managment functionality..

> subdirectories were created: drivers/evms/ for the main source code,
> and include/linux/evms/ for the header files.

What's the reason to not have the headers under drivers/evms. And why
don'T you just use drivers-md like all other volume managment drivers?

> - Add a table entry and a short function to init/do_mounts.c to
> allow an EVMS volume to be specified as the root filesystem with
> the kernel command line option "root="

Could you explain the details of how this works?

> version of EVMS was released. EVMS has been accepted into the
> Debian (Woody and Sid versions)

Can't find evms in my stock woody or sid kernel images.. (neither in the
sarge ones, btw..)

> and UnitedLinux distributions,

UL has so far merged everything IBM sent them..

It would be nice if you could attach the code you want merged,
otherwise it's pretty hards to review it

2002-10-03 14:47:52

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, 3 Oct 2002, Kevin Corry wrote:

> > I might agree with something along the lines of
> > * when evms is initialized, it's notified of all existing gendisks
> > * whenever disk is added after evms initialization, we notify evms
> > * whenever disk is removed, we notify evms
>
> This sounds like it would be exactly what EVMS needs. The only thing we would
> want to add to this list is: "*whenever a disk is modified, notify evms". For
> example, with removable media drives (such as Zip and Jaz), when a cartidge
> is changed, the capacity of the drive might change, and we would like to be
> notified of that event.

Umm... OK. There were some plans to add a notifier chain for such events
and EVMS looks like a possible user of that beast. However, it's not
obvious whether we need to do any of that in the kernel - we definitely
can have userland up and running before _any_ block devices are initialized,
so it might be a work for userland helper.

Speaking of which... Linus, mind if I start feeding initramfs stuff?

> > However, I doubt that it's what you really want. In particular, you
> > probably want to see partitioning changes as well as gendisk ones
> > (and no, "evms will handle all partitioning" is _not_ an acceptable
> > answer).
>
> EVMS won't really be interested in partitioning changes. It only cares about
> whole devices, i.e. minor_shift == 0.
>
> > Moreover, "gendisk is here" != "something is in the drive".
>
> Will there be a common method for determining "media present"? The current
> method EVMS uses to determine "media changes" is somewhat inconsistent
> between IDE and SCSI.

There's none. We need some way to deal with that, but for that we need
at least sane and stable interfaces. Right now _all_ "media changed"
stuff on the driver side is ad-hackery.

> > IOW, the real question is what are you going to do with that list of
> > gendisks?
>
> EVMS will try to read volume metadata from each device and activate volumes
> if it finds any pertinent metadata.

_Ouch_. "Each" as in...? E.g. do you want to do that for floppies? Cdroms?
EVMS volumes themselves? Things like /dev/loop? (and if yes, at which point
do you do that?)

2002-10-03 15:25:51

by Christoph Hellwig

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 10:03:41AM -0500, Shawn wrote:
> On 10/03, Christoph Hellwig said something like:
> > On Wed, Oct 02, 2002 at 04:33:20PM -0500, Kevin Corry wrote:
> > > EVMS provides a new, stand-alone subsystem to the kernel
> >
> > i.e. it duplictes existing block layer/volume managment functionality..
>
> Ok, LVM1 is non-existant if that's what you're referring to. Really,
> this replaces LVM1, but your statement WRT md still has merit. As for
> md duplication, it has been stated already that a preferred approach
> might be to send only core functionality bits for now, leaving that
> out till that question can be addressed.

I speak of all drivers/md/* and fs/partitions/*.

2002-10-03 15:21:14

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thursday 03 October 2002 09:51, Alexander Viro wrote:
> On Thu, 3 Oct 2002, Kevin Corry wrote:
> > > IOW, the real question is what are you going to do with that list of
> > > gendisks?
> >
> > EVMS will try to read volume metadata from each device and activate
> > volumes if it finds any pertinent metadata.
>
> _Ouch_. "Each" as in...? E.g. do you want to do that for floppies?
> Cdroms? EVMS volumes themselves? Things like /dev/loop? (and if yes, at
> which point do you do that?)

EVMS can filter out devices that don't make sense to probe for volumes.
Currently it ignores such things as floppies and cd-roms, as well as EVMS
volumes. We have actually added the ability to probe loop devices, though,
since we had several requests for that functionality.

--
Kevin Corry
[email protected]
http://evms.sourceforge.net/

2002-10-03 15:32:28

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, 3 Oct 2002, Kevin Corry wrote:

> On Thursday 03 October 2002 09:51, Alexander Viro wrote:
> > On Thu, 3 Oct 2002, Kevin Corry wrote:
> > > > IOW, the real question is what are you going to do with that list of
> > > > gendisks?
> > >
> > > EVMS will try to read volume metadata from each device and activate
> > > volumes if it finds any pertinent metadata.
> >
> > _Ouch_. "Each" as in...? E.g. do you want to do that for floppies?
> > Cdroms? EVMS volumes themselves? Things like /dev/loop? (and if yes, at
> > which point do you do that?)
>
> EVMS can filter out devices that don't make sense to probe for volumes.
> Currently it ignores such things as floppies and cd-roms, as well as EVMS
> volumes. We have actually added the ability to probe loop devices, though,
> since we had several requests for that functionality.

How does it recognize cdroms? Explicit list of majors? Doesn't work for
IDE and I'm fairly sure that it doesn't catch all exotic ones. Basically,
I don't believe that any methods based on keeping a registry of bad device
numbers are viable - if that information belongs anywhere, it's in drivers.

IMO the right way is to have driver set properties of gendisk and stuff
like partition-related devfs/driverfs code, RAID, evms, etc. to check
that. _If_ we handle that stuff in the kernel, that is.

The question being, what property are you looking for? "I'm suitable for
EVMS" is not an answer, obviously...

As for the loop... At which point do you want to notice it? Notice that
it can be opened earlier than anything could be read from it.

2002-10-03 14:59:04

by Shawn

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On 10/03, Christoph Hellwig said something like:
> On Wed, Oct 02, 2002 at 04:33:20PM -0500, Kevin Corry wrote:
> > EVMS provides a new, stand-alone subsystem to the kernel
>
> i.e. it duplictes existing block layer/volume managment functionality..

Ok, LVM1 is non-existant if that's what you're referring to. Really,
this replaces LVM1, but your statement WRT md still has merit. As for
md duplication, it has been stated already that a preferred approach
might be to send only core functionality bits for now, leaving that
out till that question can be addressed.

Let's take an initially critical look, both philisophically and
technically at this, but also keep an open mind. There /is/ a
difference.

--
Shawn Leas
[email protected]

My house is on the median strip of a highway. You don't really
notice, except I have to leave the driveway doing 60 MPH.
-- Stephen Wright

2002-10-03 16:10:36

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 10:51:39AM -0400, Alexander Viro wrote:
>
>
> On Thu, 3 Oct 2002, Kevin Corry wrote:
>
> > > I might agree with something along the lines of
> > > * when evms is initialized, it's notified of all existing gendisks
> > > * whenever disk is added after evms initialization, we notify evms
> > > * whenever disk is removed, we notify evms
> >
> > This sounds like it would be exactly what EVMS needs. The only thing we would
> > want to add to this list is: "*whenever a disk is modified, notify evms". For
> > example, with removable media drives (such as Zip and Jaz), when a cartidge
> > is changed, the capacity of the drive might change, and we would like to be
> > notified of that event.
>
> Umm... OK. There were some plans to add a notifier chain for such events
> and EVMS looks like a possible user of that beast. However, it's not
> obvious whether we need to do any of that in the kernel - we definitely
> can have userland up and running before _any_ block devices are initialized,
> so it might be a work for userland helper.

/sbin/hotplug already gets called for _every_ device that is added to
the system as of 2.5.40, so you should probably use that as your
userspace notifier event. If there's anything that the /sbin/hotplug
call misses, that you need for evms, please let me know.

thanks,

greg k-h

2002-10-03 16:48:48

by Patrick Mochel

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

> > > I might agree with something along the lines of
> > > * when evms is initialized, it's notified of all existing gendisks
> > > * whenever disk is added after evms initialization, we notify evms
> > > * whenever disk is removed, we notify evms
> >
> > This sounds like it would be exactly what EVMS needs. The only thing we would
> > want to add to this list is: "*whenever a disk is modified, notify evms". For
> > example, with removable media drives (such as Zip and Jaz), when a cartidge
> > is changed, the capacity of the drive might change, and we would like to be
> > notified of that event.
>
> Umm... OK. There were some plans to add a notifier chain for such events
> and EVMS looks like a possible user of that beast. However, it's not
> obvious whether we need to do any of that in the kernel - we definitely
> can have userland up and running before _any_ block devices are initialized,
> so it might be a work for userland helper.

There should be (almost) enough infrastructure in place to do either of
those things using the driver model core. There is now a disk
device_class, with which a struct device_interface can register with. When
a device is added to the class, it is passed to each of the interfaces
registered with the class (via the add_device method).

There is a struct device in struct gendisk, and each device registered
with the class will be the member of a struct gendisk. So, you can do

int add_device(struct device * dev)
{
struct gendisk * disk = container_of(dev,struct gendisk,disk_dev);
...

to get the gendisk structure.

See include/linux/device.h and Documentation/driver-model/ for more info.

Also, /sbin/hotplug will be called after a device is registered with a
class. Greg has been working on this aspect, and should be close to having
it done.

The missing piece is converting the disk drivers to have thier ->devclass
set to the disk class, and having them register with the core.

-pat

2002-10-03 16:20:44

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 07:13:11AM -0500, Kevin Corry wrote:
> On Wednesday 02 October 2002 17:43, Greg KH wrote:
> > Some comments on the code:
> > - you might want to post a patch with the whole evms portion of
> > the code, for those people without BitKeeper to see.
> > - The #ifdef EVMS_DEBUG lines are still in AIXlvm_vge.c, I
> > thought you said you were going to fix this file up?
> > - The OS2 and S390 files don't look like they have been fixed,
> > like you said you would before submission.
>
> I have been working on these, and should have them done very soon. At the
> very least, I expect to get OS2 done today. I will let you know as soon as it
> is ready.
>
> > - evms_ecr.h and evms_linear.h have a lot of unneeded typedefs.
>
> For the time being, I have removed these files from the tree. As I mentioned
> the other day, they are a long way from providing any useful clustering
> functionality.
>
> > - the md code duplication has not been addressed, as you said it
> > would be.
>
> We will be addressing this. Unfortunately, I don't see this as being a
> simple, overnight fix. Finding a way to consolidate the common code may take
> some time.

My main point about these comments is that you stated in a message a few
days ago that you would fix these issues before trying to submit the
code for inclusion in the kernel. As you can imagine, I was a bit
surprised to see them not fixed in this release you were proposing to be
included in the main tree :)

> > - the BK repository contains a _lot_ of past history and merges
> > that are probably unnecessary to have. A few, small
> > changesets are nicer to look at :)
>
> No offense meant, Greg, but that seems a bit contradictory. The way I see it,
> I can maintain our Bitkeeper tree in one of two ways.
>
> 1) Try to mirror the usage of our CVS tree. This means that each file or
> small group of files that gets checked into CVS also gets checked into
> Bitkeeper, and the comment logs can stay closely in sync. Doing this produces
> a _lot_ of _small_ changesets, but each one is fairly easy to read and
> understand. However, as you mentioned, it does produce a very long history.
>
> 2) Just do a periodic sync with the current CVS tree, maybe every three days
> or so. This will obviously produce far less history, but each changeset may
> be quite large, and thus harder to read and understand, especially since the
> comments will likely be something along the lines of "sync'ing with CVS".

Note, this is just my opinion of how to use BitKeeper, not the "rule":

You can use BitKeeper for kernel development in two ways:
- as a tree to work out of, accepting changes and doing
incremental things all along the way, including merging with
the main releases.
- or as a way to send changes to a maintainer.

I don't think you can really have it both ways, like you are trying to
do here. Your repository contains 138 changesets that are not in the
main tree. That's not a nice thing to try to make someone pull from (I
know in my USB work, I sure wouldn't do that.)

It's much nicer (this is just my opinion as a maintainer who uses
BitKeeper, I don't speak for Linus) to be presented with a tree to pull
from that _only_ contains a small number of changes. Not 138 different
changes.

So I recommend you use two BitKeeper trees. One to do your work out of
(much like the one you have today), and one that you use to send changes
to other people with. I know the JFS group does it this way, if you
want to see another example besides the USB group.

> So, I will send in a few patches that introduce just the core code so
> everyone can get a good look. There will be four files coming: evms.c,
> evms.h, evms_ioctl.h, and evms_biosplit.h.

Thank you, that sounds like a much saner approach.

thanks,

greg k-h

2002-10-03 16:48:23

by Linus Torvalds

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, 3 Oct 2002, Greg KH wrote:
>
> You can use BitKeeper for kernel development in two ways:
> - as a tree to work out of, accepting changes and doing
> incremental things all along the way, including merging with
> the main releases.
> - or as a way to send changes to a maintainer.
>
> I don't think you can really have it both ways

I think this is a pretty good point, and is something that I don't think
anybody has ever really said explicitly before.

Some of the BK usage documentation (or "hints") by Jeff clearly imply this
behaviour, but it's not really stated explicitly anywhere.

Also note that using multiple trees is pretty easy - you _can_ easily do
development in the "export" tree, if you just make sure that you only do
one kind of development. And then you have a separate "test" tree that is
a "throw-away combination tree" which just pulls all the other trees and
has the combination of all the different work trees.

That multi-tree approach has advantages quite outside of merging cleanly:
it means that when trouble happens, and something doesn't work, it's
really easy to test out other changes.

I personally often use the multi-tree approach myself when merging bigger
changes (especially if there are other changes that are in the same area):
before I apply something big, I clone my regular tree (often down
to a known version, like the last release), and apply those changes in
that separate tree.

Then I build and test that separate tree before I merge it into my "final
merge" tree - it makes it easier to see whether problems are due to a
specific line of patches, or whether it might be some interaction between
different changes.

> Your repository contains 138 changesets that are not in the main tree.
> That's not a nice thing to try to make someone pull from (I know in my
> USB work, I sure wouldn't do that.)

One reason it's so easy to merge with the USB people (and with Jeff and
David and a number of others too, for that matter) is exactly the fact
that when I get an email that says "pull this tree to get these USB
changes", that is all I get. Not "random support changes to other parts of
the kernel that I also used on my tree".

If I don't get a clean BK tree to pull from, I just cannot pull it. I end
up applying the diffs by hand instead, at which point when I push out my
end result, the original source of the patches does _not_ get a clean BK
tree that matches mine, but instead gets a BK tree that has the changes
TWICE, in addition to all the crud it already had.

Which now makes it doubly hard to see which parts I applied, and which
ones I didn't - BK will usually have successfully merged the trees, but
you don't actually get any real "source control". You only get a messy
tree.

As a result, such a tree is even _less_ useful than it was last time, and
definitely will never be pulled by me ever again, and the poor kernel
developer ends up not getting any of the real advantages of BK at all.

> So I recommend you use two BitKeeper trees. One to do your work out of
> (much like the one you have today), and one that you use to send changes
> to other people with. I know the JFS group does it this way, if you
> want to see another example besides the USB group.

Or even more than just two - multiple different trees to develop in and
push from. You obviously has the USB tree, but also the pci hotplug one.
Jeff has his network driver tree, and separate trees for misc things (or
separate trees for different drivers).

Davem has his networking tree and his sparc tree and often a separate
"misc" tree where he pushes the very occasional stuff that is neither.
And Kai has the ISDN tree and the kbuild tree.

In fact, _most_ people that merge with me using BK seem to use more than
one tree already (some developers are very specialized and only have the
one tree: JFS and ARM come to mind).

I think it's very much a "getting used to the experience". Some people
don't like it, and that's fine - I have absolutely no problem applying
clean patches either, and some of the major kernel developers have never
used a BK tree to merge with me (Andrew, Viro, Alan, Ingo..) and it hasn't
been a problem.

I personally think there is a very simple rule to using BK: if you're
doing development, and you only have one tree, you're doing something
wrong. The "single tree" approach is fine if your use of BK is really more
of a "anonymous CVS" replacement - you use BK only to track somebody elses
tree and build that. But if you do real development, you should have
multiple trees, or you're not really using BK as a SCM.

Linus

2002-10-03 16:27:34

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 12:21:13PM -0400, Alexander Viro wrote:
> On Thu, 3 Oct 2002, Greg KH wrote:
> > /sbin/hotplug already gets called for _every_ device that is added to
> > the system as of 2.5.40, so you should probably use that as your
> > userspace notifier event. If there's anything that the /sbin/hotplug
> > call misses, that you need for evms, please let me know.
>
> We need it
> a) early enough

Your initramfs patches will enable this to happen :)

> b) called for things like umem, etc. - random drivers built into
> the tree and exporting several block devices.

All devices that have a "struct device" (which should be about
everything these days, if not, please let me know), cause a
/sbin/hotplug event to happen. This event says what type of device was
added or removed, and includes the location of the device in the
driverfs tree so that userspace can then determine what it wants to do
with this device.

I'm working on adding a call to /sbin/hotplug when classes are
registered with the kernel (like disk and other things that live in the
class driverfs tree).

Is this enough information to do what you need?

thanks,

greg k-h

2002-10-03 16:15:51

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, 3 Oct 2002, Greg KH wrote:

> > Umm... OK. There were some plans to add a notifier chain for such events
> > and EVMS looks like a possible user of that beast. However, it's not
> > obvious whether we need to do any of that in the kernel - we definitely
> > can have userland up and running before _any_ block devices are initialized,
> > so it might be a work for userland helper.
>
> /sbin/hotplug already gets called for _every_ device that is added to
> the system as of 2.5.40, so you should probably use that as your
> userspace notifier event. If there's anything that the /sbin/hotplug
> call misses, that you need for evms, please let me know.

We need it
a) early enough
b) called for things like umem, etc. - random drivers built into
the tree and exporting several block devices.

2002-10-03 17:25:06

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 10:00:29AM -0700, David Lang wrote:
> Greg, please note that while there are people planning to change the
> kernel to require an initramfs to boot on any machine, there are a number
> of people who disagree with this approach, since the initramfs changes to
> make it possible to be mandatory are not in the kernel yet (let alone the
> flame war^H^H^H^H^H^H^H^H^Hdiscussion that will take place before
> initramfs is made mandatory) you can't tell Kevin to build his code in
> such a way that it only works if you have it.
>
> once initramfs is to the point where it can be made mandatory, then if
> Linus states that he wants to mandate drivers as modules useing initramfs,
> then you can tell new drivers they can't be compiled in and can depend on
> userspace tools like /sbin/hotplug.

Hm, I think you're a bit confused here.

/sbin/hotplug has nothing to do with modules. It works just fine with a
kernel with everything built in. /sin/hotplug is getting called when
anything in the system changes, like a device is discovered or removed.

Now the fact that the current hotplug package that implements a version
of /sbin/hotplug only really handles loading new modules for devices
that do not currently have drivers bound to them, is only an
implementation detail. The hotplug package will start to change soon,
based on the new information that is being spit out by your kernel.

> given that we had a patch a week or so ago to change how modules get
> loaded into memory to avoid a 'several percentage point' speed difference
> between modules and built-in and that the people pushing 'do everything in
> initramfs' have been saying for years that there is no performance
> difference I for one am not convinced that mandating initramfs is a good
> thing.

initramfs and "everything must be a module" are two different
discussions. Only after the first happens can we even start talking
about the second.

And even if we don't ever agree that everything has to be a module, the
initramfs implementation moves a whole lot of crap out of kernel space,
and into userspace, that I can't see any good reason not to have it.

But let's wait for Al's latest initramfs patches to start talking about
that topic, I thought this thread was about evms :)

thanks,

greg k-h

2002-10-03 17:03:48

by David Lang

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

Greg, please note that while there are people planning to change the
kernel to require an initramfs to boot on any machine, there are a number
of people who disagree with this approach, since the initramfs changes to
make it possible to be mandatory are not in the kernel yet (let alone the
flame war^H^H^H^H^H^H^H^H^Hdiscussion that will take place before
initramfs is made mandatory) you can't tell Kevin to build his code in
such a way that it only works if you have it.

once initramfs is to the point where it can be made mandatory, then if
Linus states that he wants to mandate drivers as modules useing initramfs,
then you can tell new drivers they can't be compiled in and can depend on
userspace tools like /sbin/hotplug.

given that we had a patch a week or so ago to change how modules get
loaded into memory to avoid a 'several percentage point' speed difference
between modules and built-in and that the people pushing 'do everything in
initramfs' have been saying for years that there is no performance
difference I for one am not convinced that mandating initramfs is a good
thing.

David Lang

On Thu, 3 Oct 2002, Greg KH wrote:

> Date: Thu, 3 Oct 2002 09:30:19 -0700
> From: Greg KH <[email protected]>
> To: Alexander Viro <[email protected]>
> Cc: Kevin Corry <[email protected]>, [email protected],
> [email protected], [email protected]
> Subject: Re: EVMS Submission for 2.5
>
> On Thu, Oct 03, 2002 at 12:21:13PM -0400, Alexander Viro wrote:
> > On Thu, 3 Oct 2002, Greg KH wrote:
> > > /sbin/hotplug already gets called for _every_ device that is added to
> > > the system as of 2.5.40, so you should probably use that as your
> > > userspace notifier event. If there's anything that the /sbin/hotplug
> > > call misses, that you need for evms, please let me know.
> >
> > We need it
> > a) early enough
>
> Your initramfs patches will enable this to happen :)
>
> > b) called for things like umem, etc. - random drivers built into
> > the tree and exporting several block devices.
>
> All devices that have a "struct device" (which should be about
> everything these days, if not, please let me know), cause a
> /sbin/hotplug event to happen. This event says what type of device was
> added or removed, and includes the location of the device in the
> driverfs tree so that userspace can then determine what it wants to do
> with this device.
>
> I'm working on adding a call to /sbin/hotplug when classes are
> registered with the kernel (like disk and other things that live in the
> class driverfs tree).
>
> Is this enough information to do what you need?
>
> thanks,
>
> greg k-h
> -
> 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/
>

2002-10-03 19:19:14

by Linus Torvalds

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, 3 Oct 2002, Alexander Viro wrote:
>
> Speaking of which... Linus, mind if I start feeding initramfs stuff?

Go wild.

Linus

2002-10-03 21:28:29

by Oliver Neukum

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

> All devices that have a "struct device" (which should be about
> everything these days, if not, please let me know), cause a
> /sbin/hotplug event to happen. This event says what type of device was
> added or removed, and includes the location of the device in the
> driverfs tree so that userspace can then determine what it wants to do
> with this device.

device != medium
There's a need to report that as well. The current hotplugging model
needs some more types of events before it is ready for all types of
applications.
In fact a change of medium can radically alter features of a device,
eg. from ro to rw.

Regards
Oliver

2002-10-03 21:35:34

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 09:52:12PM +0200, Oliver Neukum wrote:
>
> device != medium
> There's a need to report that as well.

I completely agree. That's why I'm working on adding class support to
/sbin/hotplug which will enable all "mediums" that are added or removed
within the kernel to notify userspace of this event.

thanks,

greg k-h

2002-10-03 22:23:50

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Wednesday 02 October 2002 17:43, Greg KH wrote:
> Some comments on the code:

> - The #ifdef EVMS_DEBUG lines are still in AIXlvm_vge.c, I
> thought you said you were going to fix this file up?
> - The OS2 and S390 files don't look like they have been fixed,
> like you said you would before submission.

Greg,

I have finished the cleanup and port to 2.5 for the OS2 plugin. AIX has also
gone through some cursory cleanup, and the #ifdef's you mentioned should be
gone. If you're still interested, please take a look and let me know if that
is more along the lines of what you are looking for. The 390 plugin will
hopefully come tomorrow.

Bitkeeper: http://evms.bkbits.net/linux-2.5
CVS: http://sourceforge.net/cvs/?group_id=25076
or
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/evms/runtime/linux-2.5/

--
Kevin Corry
[email protected]
http://evms.sourceforge.net/

2002-10-03 22:18:25

by Oliver Neukum

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

On Thursday 03 October 2002 23:37, Greg KH wrote:
> On Thu, Oct 03, 2002 at 09:52:12PM +0200, Oliver Neukum wrote:
> > device != medium
> > There's a need to report that as well.
>
> I completely agree. That's why I'm working on adding class support to
> /sbin/hotplug which will enable all "mediums" that are added or removed
> within the kernel to notify userspace of this event.

Ehm, how ?
Perhaps this is a misunderstanding.
You need to report changes of the actual physical medium of eg. a zip drive.
How you want to do this from a class driver, I fail to see.

Beside that you need of course to report things like iscsi which have volumes,
but not really devices.

Regards
Oliver

2002-10-03 22:57:59

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

On Thu, 3 Oct 2002, Greg KH wrote:

> On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> > Perhaps this is a misunderstanding.
> > You need to report changes of the actual physical medium of eg. a zip drive.
> > How you want to do this from a class driver, I fail to see.
>
> When a "medium" goes away from the system, it is unregistered somehow,
> right? So, in the disk class, that device would disappear, and cause
> the /sbin/hotplug event.
>
> This is assuming that we can detect media changes, which is a whole
> different topic that I don't want to get involved with :)

Our mechanism is retroactive. We can (kinda-sorta) tell "did the
media change happen since the last time we'd asked". That's it.
And even that is less than accurate - many drivers decide to be on
the safe side and _always_ answer "yes, it did".

And yes, it sucks.

2002-10-03 22:53:55

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> Perhaps this is a misunderstanding.
> You need to report changes of the actual physical medium of eg. a zip drive.
> How you want to do this from a class driver, I fail to see.

When a "medium" goes away from the system, it is unregistered somehow,
right? So, in the disk class, that device would disappear, and cause
the /sbin/hotplug event.

This is assuming that we can detect media changes, which is a whole
different topic that I don't want to get involved with :)

> Beside that you need of course to report things like iscsi which have
> volumes, but not really devices.

But iscsi registers these "volumes" with the scsi layer, right? If so,
everything is fine (take a look at the driverfs scsi tree right now,
it's a bit messy, but you get the idea.). If iscsi doesn't register
these volumes with the scsi layer, how does the scsi layer know to talk
to them?

In other words, if the kernel knows about a type of device, which I'm
pretty sure it has to in order to talk to it, that device will generate
/sbin/hotplug events when it shows up and is removed.

As for implementation details, if you see a type of device right now
that does not generate these kinds of events, please let me know.

thanks,

greg k-h

2002-10-03 23:04:47

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thu, Oct 03, 2002 at 04:56:37PM -0500, Kevin Corry wrote:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/evms/runtime/linux-2.5/

Heh, looks like you ran the thing through Lindent without looking at the
output. Lindent is a great place to start, but it does generate lines
like the following which you will probably want to fix up by hand
(unless you really want to try to maintain things like this...)

volume_group->
volume_list[AIXppent->
lv_index -
1]->
le_to_pe_map_mir1
[le_number].
pe_sector_offset = offset;

oh, here's another one that's even messier:

volume_group->
volume_list
[AIXppent->
lv_index -
1]->
le_to_pe_map_mir2
[le_number].
pe_sector_offset =
offset;

You also have a number of local variables that use InterCaps.

But, 80 column rants aside, the code looks much better, thank you for
cleaning it up.

thanks,

greg k-h

2002-10-04 01:19:40

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Thursday 03 October 2002 18:07, Greg KH wrote:
> On Thu, Oct 03, 2002 at 04:56:37PM -0500, Kevin Corry wrote:
> >
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/evms/runtime/linux-2.5/
>
> Heh, looks like you ran the thing through Lindent without looking at the
> output. Lindent is a great place to start, but it does generate lines
> like the following which you will probably want to fix up by hand
> (unless you really want to try to maintain things like this...)

Yep, you guessed it. I'm no big fan of Lindent. In my opinion, it makes some
really bad choices about how to break long lines (among other things), as
you've kindly pointed out. But, I had to start somewhere and wanted to get
something out before I left for the day. Obviously the AIX plugin will need
some additional attention at some point.

-Kevin

2002-10-04 09:26:04

by Oliver Neukum

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

On Friday 04 October 2002 00:56, Greg KH wrote:
> On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> > Perhaps this is a misunderstanding.
> > You need to report changes of the actual physical medium of eg. a zip
> > drive. How you want to do this from a class driver, I fail to see.
>
> When a "medium" goes away from the system, it is unregistered somehow,
> right? So, in the disk class, that device would disappear, and cause
> the /sbin/hotplug event.

Well, sadly this is not the case. You can put a medium into a drive and
pull it out without the kernel ever noticing. Unless of course you try to use
the thing. But even in this case there's no hotplug event.
Yet user space and evms have to learn about it in the long term.
Changing a medium can mean that a new type of medium is inserted.
A modern zip drive goes from 100M(ro) to 250M(rw) and even 750M(rw)
We need to know and report.

> This is assuming that we can detect media changes, which is a whole
> different topic that I don't want to get involved with :)

Your wishes you are entiteled to ;-) Unfortunately this is not a viable
position speaking long term.

> > Beside that you need of course to report things like iscsi which have
> > volumes, but not really devices.
>
> But iscsi registers these "volumes" with the scsi layer, right? If so,
> everything is fine (take a look at the driverfs scsi tree right now,
> it's a bit messy, but you get the idea.). If iscsi doesn't register
> these volumes with the scsi layer, how does the scsi layer know to talk
> to them?

I'll look at the source.

> In other words, if the kernel knows about a type of device, which I'm
> pretty sure it has to in order to talk to it, that device will generate
> /sbin/hotplug events when it shows up and is removed.
>
> As for implementation details, if you see a type of device right now
> that does not generate these kinds of events, please let me know.

Device management is all right, but volume management operates at the
medium level, or rather in between. What do you do if somebody adds drives
to a SCSI-RAID converter.
Evms currently polls on demand. I see no way to do it differently with
the present infrastructure.

Regards
Oliver

2002-10-04 12:52:57

by Alan

[permalink] [raw]

Subject: Re: EVMS Submission for 2.5

On Fri, 2002-10-04 at 01:39, Kevin Corry wrote:
> Yep, you guessed it. I'm no big fan of Lindent. In my opinion, it makes some
> really bad choices about how to break long lines (among other things), as
> you've kindly pointed out. But, I had to start somewhere and wanted to get
> something out before I left for the day. Obviously the AIX plugin will need
> some additional attention at some point.

IMHO the Lindent script is broken. It should also specify a line length
of something like 256 so it doesnt go mashing lines.

2002-10-04 13:34:47

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

On Friday 04 October 2002 08:06, Alan Cox wrote:
> On Fri, 2002-10-04 at 01:39, Kevin Corry wrote:
> > Yep, you guessed it. I'm no big fan of Lindent. In my opinion, it makes
> > some really bad choices about how to break long lines (among other
> > things), as you've kindly pointed out. But, I had to start somewhere and
> > wanted to get something out before I left for the day. Obviously the AIX
> > plugin will need some additional attention at some point.
>
> IMHO the Lindent script is broken. It should also specify a line length
> of something like 256 so it doesnt go mashing lines.

Well, currently the Lindent script specifies a line length of 80 characters.
Should this be changed?

indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@"
^^^^

The CodingStyle document doesn't seem to specifically mention line length,
but does imply in a couple of places that code should fit nicely on a
80-column, 24/25-line terminal.

--
Kevin Corry
[email protected]
http://evms.sourceforge.net/

2002-10-04 18:39:49

by kaih

[permalink] [raw]

Subject: Re: [Evms-devel] Re: EVMS Submission for 2.5

[email protected] (Kevin Corry) wrote on 04.10.02 in <02100408071900.02266@boiler>:

> On Friday 04 October 2002 08:06, Alan Cox wrote:

> > IMHO the Lindent script is broken. It should also specify a line length
> > of something like 256 so it doesnt go mashing lines.
>
> Well, currently the Lindent script specifies a line length of 80 characters.
> Should this be changed?
>
> indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@"
> ^^^^
>
> The CodingStyle document doesn't seem to specifically mention line length,
> but does imply in a couple of places that code should fit nicely on a
> 80-column, 24/25-line terminal.

I'd say that keeping the lines at 80 max is a real requirement, but
Lindent is a bad way to implement it, as it just isn't intelligent enough
to find good breaks in overly long lines.

MfG Kai

2002-10-05 00:03:41