EVMS Submission for 2.5

I don't know about everyone else, but I'm hoping this gets included.

I wonder where volume mgmt is going for (2.6|3.0)? I hope it does not die a terrible neglected death.

Given the history of interaction between the LVM team's maintenance style and Linus, I wonder if he'll give EVMS a go...

(For those of you who weren't watching the debates about LVM updates never appearing in mainline, that's what I'm referring to...)

On 10/02, Kevin Corry said something like:

Quoted 4 lines

Linus,
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.

--
Shawn Leas
[email protected]

My grandfather invented Cliff's Notes. It all started back in 1912... well, to make a long story short...
-- Stephen Wright

Shawn

2002-10-02 22:23 UTC #2 lore raw

Since I am personally hoping for EVMSs inclusion, I just wanted to thank you for being constructive in pointing out specific issues so that they can be addressed.

Hopefully, folks can keep from starting a religious war. This /is/ fertile ground for one, too... Heavyweights have weighed in on all sides of this fence, making (md|.*Volume Manage\S+) a very contentious topic...

On 10/02, Alexander Viro said something like:

Quoted 10 lines · Kevin Corry

Quoted 8 lines
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).

Quoted 7 lines

Quoted 3 lines
- 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.

--
Shawn Leas
[email protected]

I got a new shadow. I had to get rid of the other one
-- it wasn't doing
what I was doing.
-- Stephen Wright

Kevin Corry

author

2002-10-02 22:30 UTC #3 lore raw

Quoted 10 lines · Alexander Viro

Quoted 9 lines · Kevin Corry
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).

Quoted 7 lines

Quoted 3 lines
- 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?

Signature · 3 lines

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

Greg KH

2002-10-02 22:40 UTC #24 lore raw

Quoted 5 lines · Kevin Corry

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

Alexander Viro

2002-10-02 22:57 UTC #4 lore raw

Quoted 4 lines · Kevin Corry

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?

Kevin Corry

author

2002-10-03 12:40 UTC #25 lore raw

Quoted 7 lines · Greg KH

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.

Quoted 1 line

- 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.

Quoted 2 lines

- 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.

Quoted 3 lines

- 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".

Quoted 4 lines

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.

Signature · 3 lines

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

Kevin Corry

author

2002-10-03 13:32 UTC #5 lore raw

Quoted 7 lines · Alexander Viro

Quoted 5 lines · Kevin Corry
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?

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 2 lines

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.

Signature · 3 lines

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

Christoph Hellwig

2002-10-03 14:28 UTC #34 lore raw

Quoted 1 line · Kevin Corry

EVMS provides a new, stand-alone subsystem to the kernel

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

Quoted 2 lines

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?

Quoted 3 lines

- 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?

Quoted 2 lines

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..)

Quoted 1 line

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

Alexander Viro

2002-10-03 14:47 UTC #6 lore raw

In reply to Christoph Hellwig

Quoted 10 lines · Kevin Corry

Quoted 4 lines
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?

Quoted 5 lines

Quoted 4 lines
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).

Quoted 8 lines

EVMS won't really be interested in partitioning changes. It only cares about whole devices, i.e. minor_shift == 0.
Quoted 1 line
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.

Quoted 5 lines

Quoted 2 lines
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?)

Michael Clark

2002-10-03 14:54 UTC #35 lore raw

Quoted 6 lines · Christoph Hellwig

Quoted 2 lines
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..)

Ships as a kernel patch deb as per most other debian kernel stuff that isn't in mainline (debian kernel images are always unpatched mainline)

This is on my sid machine

$ apt-cache pkgnames | grep evms
evms-ncurses
libevms0
libevms1
evms-cli
evms-gui
kernel-patch-evms
libevms-dev
evms-lvmutils
evms

This is on one of my woody machines

$ apt-cache pkgnames | grep evms
evms-ncurses
libevms0
libevms1
evms-cli
evms-gui
kernel-patch-evms
libevms-dev
evms-lvmutils
evms

~mc

Shawn

2002-10-03 14:59 UTC #37 lore raw

In reply to Christoph Hellwig

On 10/03, Christoph Hellwig said something like:

Quoted 4 lines · Kevin Corry

Quoted 1 line
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

Christoph Hellwig

2002-10-03 15:03 UTC #36 lore raw

In reply to Michael Clark

Quoted 1 line

(debian kernel images are always unpatched mainline)

The diff is pretty huge for 'unpatched'.

Kevin Corry

author

2002-10-03 15:21 UTC #7 lore raw

Quoted 10 lines · Alexander Viro

Quoted 5 lines · Kevin Corry
Quoted 2 lines
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.

Signature · 3 lines

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

Christoph Hellwig

2002-10-03 15:25 UTC #38 lore raw

In reply to Shawn

Quoted 11 lines · Shawn

On 10/03, Christoph Hellwig said something like:
Quoted 4 lines · Kevin Corry
Quoted 1 line
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/*.

Alexander Viro

2002-10-03 15:32 UTC #8 lore raw

In reply to Christoph Hellwig

Quoted 8 lines · Kevin Corry

Quoted 7 lines · Alexander Viro
Quoted 5 lines · Kevin Corry
Quoted 2 lines
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.

Quoted 8 lines

Quoted 3 lines
_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.

Mike Tran

2002-10-03 15:42 UTC #39 lore raw

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Shawn
On 10/03, Christoph Hellwig said something like:
Quoted 4 lines · Kevin Corry
Quoted 1 line
EVMS provides a new, stand-alone subsystem to the kernel
i.e. it duplictes existing block layer/volume managment functionality..

Quoted 8 lines

Quoted 5 lines
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/*.

I have sent Neil Brown an email asking for his thoughts on a possible code merge.
Neil is on vacation until 10/7.

I would say that the EMVS MD code & original MD code are very similar. The most significant difference is the MD array discovery and setup code. EVMS MD does in-kernel discovery, whereas Linux MD has both in-kernel discovery (via fs/partitions/check.c) and user space initiated discovery (IOCTL).

Mike Tran

Greg KH

2002-10-03 16:10 UTC #9 lore raw

Quoted 15 lines · Alexander Viro

Quoted 10 lines · Kevin Corry
Quoted 4 lines
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.

Quoted 5 lines

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

Alexander Viro

2002-10-03 16:15 UTC #10 lore raw

Quoted 10 lines · Greg KH

Quoted 5 lines
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.

Greg KH

2002-10-03 16:20 UTC #26 lore raw

Quoted 19 lines · Kevin Corry

Quoted 7 lines · Greg KH
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.
Quoted 1 line
- 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.

Quoted 6 lines

Quoted 2 lines
- 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 :)

Quoted 13 lines

Quoted 3 lines
- 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.

Quoted 4 lines

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.

Quoted 3 lines

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

Greg KH

2002-10-03 16:27 UTC #11 lore raw

Quoted 8 lines · Alexander Viro

Quoted 4 lines · Greg KH
/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 :)

Quoted 2 lines

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

Linus Torvalds

2002-10-03 16:48 UTC #27 lore raw

Quoted 8 lines · Greg KH

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.

Quoted 3 lines

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.

Quoted 4 lines

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

Patrick Mochel

2002-10-03 16:48 UTC #21 lore raw

Quoted 12 lines

Quoted 11 lines
Quoted 5 lines
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.

Quoted 5 lines

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

David Lang

2002-10-03 17:03 UTC #12 lore raw

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

Quoted 44 lines · Greg KH

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
Quoted 8 lines · Alexander Viro
Quoted 4 lines · Greg KH
/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 :)
Quoted 2 lines
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/

Greg KH

2002-10-03 17:25 UTC #13 lore raw

Quoted 8 lines · David Lang

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.

Quoted 4 lines

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.

Quoted 6 lines

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

Linus Torvalds

2002-10-03 19:19 UTC #22 lore raw

Quoted 2 lines · Alexander Viro

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

Go wild.

Linus

Oliver Neukum

2002-10-03 21:28 UTC #14 lore raw

Quoted 7 lines

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

Greg KH

2002-10-03 21:35 UTC #15 lore raw

Quoted 3 lines · Oliver Neukum

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

Oliver Neukum

2002-10-03 22:18 UTC #16 lore raw

Quoted 7 lines · Greg KH

Quoted 2 lines · Oliver Neukum
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

Kevin Corry

author

2002-10-03 22:23 UTC #28 lore raw

In reply to Oliver Neukum

Quoted 6 lines · Greg KH

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/

Signature · 3 lines

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

Greg KH

2002-10-03 22:53 UTC #17 lore raw

Quoted 3 lines · Oliver Neukum

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 :)

Quoted 2 lines

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

Alexander Viro

2002-10-03 22:57 UTC #18 lore raw

Quoted 11 lines · Greg KH

Quoted 3 lines · Oliver Neukum
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.

Greg KH

2002-10-03 23:04 UTC #29 lore raw

Quoted 1 line · Kevin Corry

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

Kevin Corry

2002-10-04 01:19 UTC #30 lore raw

Quoted 8 lines · Greg KH

Quoted 2 lines · Kevin Corry
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

Oliver Neukum

2002-10-04 09:26 UTC #19 lore raw

Quoted 8 lines · Greg KH

Quoted 3 lines · Oliver Neukum
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.

Quoted 2 lines

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.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 6 lines

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

Alan Cox

2002-10-04 12:52 UTC #31 lore raw