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

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

[Steve Pratt]

Christoph Hellwig wrote:

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

None, really. Why does md put it's headers in include/linux/raid ???
We can put them wherever.

> And why don'T you just use drivers-md like all other volume management
drivers?

Because it is getting crowded.  Why does every filesystem create it's own
directory in fs?  Maybe drivers/vm/md drivers/vm/dm drivers/vm/evms would
be better.  Again, we can put it wherever, this just seems like a logical
place.

Steve

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

[Christoph Hellwig]

On Thu, Oct 03, 2002 at 11:09:37AM -0500, Steve Pratt wrote:
> None, really. Why does md put it's headers in include/linux/raid ???
> We can put them wherever.

MD is legacy code from the time where people still liked kernel headers
to /usr/include/linux

> Because it is getting crowded.  Why does every filesystem create it's own
> directory in fs?

Well, evms is not a single driver but a higher layer with lots of subdrivers.
E.g. once you start to use the MD code without copying it around it's in
drivers/md anyway and LVM! thæt is there currently will go away.

Re: EVMS Submission for 2.5

[Greg KH]

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

Re: EVMS Submission for 2.5

[Alexander Viro]

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.

Re: EVMS Submission for 2.5

[Greg KH]

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

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

[Oliver Neukum]

> 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

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

[Greg KH]

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

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

[Oliver Neukum]

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

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

[Greg KH]

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

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

[Alexander Viro]

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.

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

[Oliver Neukum]

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

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

[Greg KH]

On Fri, Oct 04, 2002 at 10:07:24AM +0200, Oliver Neukum wrote:
> 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.

I agree we need to know this.  And if the kernel figures it out
(somehow) then userspace should also be told about this, through
/sbin/hotplug.  That's all I'm saying.


thanks,

greg k-h

EVMS Submission for 2.5

[Kevin Corry]

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.

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

EVMS provides a new, stand-alone subsystem to the kernel. Two new
subdirectories were created: drivers/evms/ for the main source code,
and include/linux/evms/ for the header files. There is no functional
affect on the existing kernel, and users can of course choose to
enable or disable EVMS when configuring their kernel.

In addition to the actual EVMS code, a handful of existing kernel
files were modified to allow EVMS to build and run correctly. I have
included below a patch (against 2.5.40) with these changes for you
to inspect. These changes are obviously also part of the Bitkeeper
tree above. Here are the changes in a nutshell:
- Add our contact info to the MAINTAINERS file.
- Add config options for EVMS to the config.in files for i386, ia64,
  parisc, ppc, ppc64, s390, s390x, and x86_64.
- Add evms to the list of build directories in drivers/Makefile
- 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.
- Add function prototyes to fs.h and genhd.h
- Add the EVMS assigned major number (117) to major.h
- Add entries to sysctl.h to allow access to some EVMS internal
  variables.
- 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="

EVMS 1.0 was officially released in March of this year and is
building a strong base of users. Just this week, the new 1.2
version of EVMS was released. EVMS has been accepted into the
Debian (Woody and Sid versions) and UnitedLinux distributions,
well as a number of smaller distros. EVMS is actively undergoing
improvements and upgrades, and if it is accepted into the kernel,
we will serve as the active maintainers.

If you are interested in other information about EVMS, or would
like to obtain the user-space administration tools, please visit
our website at http://evms.sourceforge.net/.

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.

Thank you,

Kevin Corry
corryk@us.ibm.com

Mark Peloquin
peloquin@us.ibm.com

Steve Pratt
slpratt@us.ibm.com

diff -Naur linux-2002-10-01/MAINTAINERS evms-2002-10-01/MAINTAINERS
--- linux-2002-10-01/MAINTAINERS	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/MAINTAINERS	Tue Oct  1 15:18:41 2002
@@ -556,6 +556,13 @@
 W:	http://opensource.creative.com/
 S:	Maintained
 
+ENTERPRISE VOLUME MANAGEMENT SYSTEM (EVMS)
+P:	Mark Peloquin, Steve Pratt, Kevin Corry
+M:	peloquin@us.ibm.com, slpratt@us.ibm.com, corryk@us.ibm.com
+L:	evms-devel@lists.sourceforge.net
+W:	http://www.sourceforge.net/projects/evms/
+S:	Supported
+
 ETHEREXPRESS-16 NETWORK DRIVER
 P:	Philip Blundell
 M:	Philip.Blundell@pobox.com
diff -Naur linux-2002-10-01/arch/i386/config.in evms-2002-10-01/arch/i386/config.in
--- linux-2002-10-01/arch/i386/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/i386/config.in	Tue Oct  1 15:18:41 2002
@@ -368,6 +368,8 @@
 fi
 endmenu
 
+source drivers/evms/Config.in
+
 source drivers/md/Config.in
 
 source drivers/message/fusion/Config.in
diff -Naur linux-2002-10-01/arch/ia64/config.in evms-2002-10-01/arch/ia64/config.in
--- linux-2002-10-01/arch/ia64/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/ia64/config.in	Mon Sep 23 08:23:50 2002
@@ -146,6 +146,7 @@
   source drivers/block/Config.in
   source drivers/ieee1394/Config.in
   source drivers/message/i2o/Config.in
+  source drivers/evms/Config.in
   source drivers/md/Config.in
   source drivers/message/fusion/Config.in
 
diff -Naur linux-2002-10-01/arch/parisc/config.in evms-2002-10-01/arch/parisc/config.in
--- linux-2002-10-01/arch/parisc/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/parisc/config.in	Wed Aug 28 08:47:38 2002
@@ -90,6 +90,8 @@
 
 source drivers/block/Config.in
 
+source drivers/evms/Config.in
+
 mainmenu_option next_comment
 comment 'SCSI support'
 
diff -Naur linux-2002-10-01/arch/ppc/config.in evms-2002-10-01/arch/ppc/config.in
--- linux-2002-10-01/arch/ppc/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/ppc/config.in	Fri Sep 20 12:59:51 2002
@@ -409,6 +409,7 @@
 source drivers/mtd/Config.in
 source drivers/pnp/Config.in
 source drivers/block/Config.in
+source drivers/evms/Config.in
 source drivers/md/Config.in
 
 mainmenu_option next_comment
diff -Naur linux-2002-10-01/arch/ppc64/config.in evms-2002-10-01/arch/ppc64/config.in
--- linux-2002-10-01/arch/ppc64/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/ppc64/config.in	Mon Sep 16 08:19:02 2002
@@ -107,6 +107,8 @@
 fi
 endmenu
 
+source drivers/evms/Config.in
+
 source drivers/md/Config.in
 
 source drivers/message/fusion/Config.in
diff -Naur linux-2002-10-01/arch/s390/config.in evms-2002-10-01/arch/s390/config.in
--- linux-2002-10-01/arch/s390/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/s390/config.in	Thu Aug  8 09:39:50 2002
@@ -59,6 +59,8 @@
 
 source drivers/s390/Config.in
 
+source drivers/evms/Config.in
+
 if [ "$CONFIG_NET" = "y" ]; then
   source net/Config.in
 fi
diff -Naur linux-2002-10-01/arch/s390x/config.in evms-2002-10-01/arch/s390x/config.in
--- linux-2002-10-01/arch/s390x/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/s390x/config.in	Thu Aug  8 09:39:55 2002
@@ -62,6 +62,8 @@
 
 source drivers/s390/Config.in
 
+source drivers/evms/Config.in
+
 if [ "$CONFIG_NET" = "y" ]; then
   source net/Config.in
 fi
diff -Naur linux-2002-10-01/arch/x86_64/config.in evms-2002-10-01/arch/x86_64/config.in
--- linux-2002-10-01/arch/x86_64/config.in	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/arch/x86_64/config.in	Wed Aug 28 08:48:31 2002
@@ -117,6 +117,8 @@
 
 source drivers/block/Config.in
 
+source drivers/evms/Config.in
+
 source drivers/md/Config.in
 
 mainmenu_option next_comment
diff -Naur linux-2002-10-01/drivers/Makefile evms-2002-10-01/drivers/Makefile
--- linux-2002-10-01/drivers/Makefile	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/drivers/Makefile	Thu Aug  8 09:40:35 2002
@@ -41,5 +41,6 @@
 obj-$(CONFIG_BLUEZ)		+= bluetooth/
 obj-$(CONFIG_HOTPLUG_PCI)	+= hotplug/
 obj-$(CONFIG_ISDN_BOOL)		+= isdn/
+obj-$(CONFIG_EVMS)		+= evms/
 
 include $(TOPDIR)/Rules.make
diff -Naur linux-2002-10-01/drivers/block/genhd.c evms-2002-10-01/drivers/block/genhd.c
--- linux-2002-10-01/drivers/block/genhd.c	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/drivers/block/genhd.c	Tue Oct  1 15:19:36 2002
@@ -137,6 +137,37 @@
 
 EXPORT_SYMBOL(get_gendisk);
 
+/**
+ * walk_gendisk - issue a command for every registered gendisk
+ * @walk: user-specified callback
+ * @data: opaque data for the callback
+ *
+ * This function walks through the gendisk chain and calls back
+ * into @walk for every element.
+ */
+int
+walk_gendisk(int (*walk)(struct gendisk *, void *), void *data)
+{
+	struct gendisk *disk;
+	struct list_head *p;
+	int i, error = 0;
+
+	read_lock(&gendisk_lock);
+	for (i = 0; i < MAX_BLKDEV; i++) {
+		list_for_each(p, &gendisks[i].list) {
+			disk = list_entry(p, struct gendisk, list);
+			if ((error = walk(disk, data)))
+				goto out;
+		}
+	}
+
+out:
+	read_unlock(&gendisk_lock);
+	return error;
+}
+
+EXPORT_SYMBOL(walk_gendisk);
+
 #ifdef CONFIG_PROC_FS
 /* iterator */
 static void *part_start(struct seq_file *part, loff_t *pos)
diff -Naur linux-2002-10-01/include/linux/fs.h evms-2002-10-01/include/linux/fs.h
--- linux-2002-10-01/include/linux/fs.h	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/include/linux/fs.h	Fri Sep 20 12:59:51 2002
@@ -1284,6 +1284,7 @@
 extern struct super_block *get_super(struct block_device *);
 extern struct super_block *user_get_super(dev_t);
 extern void drop_super(struct super_block *sb);
+extern void get_root_device_name( char * root_name );
 
 extern int dcache_dir_open(struct inode *, struct file *);
 extern int dcache_dir_close(struct inode *, struct file *);
diff -Naur linux-2002-10-01/include/linux/genhd.h evms-2002-10-01/include/linux/genhd.h
--- linux-2002-10-01/include/linux/genhd.h	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/include/linux/genhd.h	Tue Oct  1 15:19:47 2002
@@ -95,6 +95,7 @@
 extern void del_gendisk(struct gendisk *gp);
 extern void unlink_gendisk(struct gendisk *gp);
 extern struct gendisk *get_gendisk(dev_t dev, int *part);
+extern int walk_gendisk(int (*walk)(struct gendisk *, void *), void *data);
 static inline unsigned long get_start_sect(struct block_device *bdev)
 {
 	return bdev->bd_offset;
diff -Naur linux-2002-10-01/include/linux/major.h evms-2002-10-01/include/linux/major.h
--- linux-2002-10-01/include/linux/major.h	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/include/linux/major.h	Wed Jul 10 08:27:47 2002
@@ -140,6 +140,8 @@
 
 #define LVM_CHAR_MAJOR	109	/* Logical Volume Manager */
 
+#define EVMS_MAJOR	117	/* Enterprise Volume Management System */
+
 #define RTF_MAJOR	150
 #define RAW_MAJOR	162
 
diff -Naur linux-2002-10-01/include/linux/sysctl.h evms-2002-10-01/include/linux/sysctl.h
--- linux-2002-10-01/include/linux/sysctl.h	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/include/linux/sysctl.h	Fri Sep 20 12:59:51 2002
@@ -578,7 +578,8 @@
 	DEV_HWMON=2,
 	DEV_PARPORT=3,
 	DEV_RAID=4,
-	DEV_MAC_HID=5
+	DEV_MAC_HID=5,
+	DEV_EVMS=6
 };
 
 /* /proc/sys/dev/cdrom */
@@ -594,6 +595,18 @@
 /* /proc/sys/dev/parport */
 enum {
 	DEV_PARPORT_DEFAULT=-3
+};
+
+/* /proc/sys/dev/evms */
+enum {
+	DEV_EVMS_INFO_LEVEL=1,
+	DEV_EVMS_MD=2
+};
+
+/* /proc/sys/dev/evms/raid */
+enum {
+	DEV_EVMS_MD_SPEED_LIMIT_MIN=1,
+	DEV_EVMS_MD_SPEED_LIMIT_MAX=2
 };
 
 /* /proc/sys/dev/raid */
diff -Naur linux-2002-10-01/init/do_mounts.c evms-2002-10-01/init/do_mounts.c
--- linux-2002-10-01/init/do_mounts.c	Tue Oct  1 15:20:49 2002
+++ evms-2002-10-01/init/do_mounts.c	Tue Sep 10 10:54:14 2002
@@ -213,6 +213,7 @@
 	{ "ftlc", 0x2c10 },
 	{ "ftld", 0x2c18 },
 	{ "mtdblock", 0x1f00 },
+	{ "evms", 0x7500 },
 	{ NULL, 0 }
 };
 
@@ -728,6 +729,11 @@
 	}
 #endif
 	mount_block_root("/dev/root", root_mountflags);
+}
+
+void get_root_device_name( char * root_name )
+{
+	strncpy(root_name, root_device_name, 63);
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD

Re: EVMS Submission for 2.5

[Christoph Hellwig]

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

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

[Michael Clark]

On 10/03/02 22:32, Christoph Hellwig wrote:

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

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

[Christoph Hellwig]

> (debian kernel images are always unpatched mainline)

The diff is pretty huge for 'unpatched'.

Re: EVMS Submission for 2.5

[Shawn]

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
core@enodev.com

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

Re: EVMS Submission for 2.5

[Christoph Hellwig]

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

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

[Mike Tran]

Christoph Hellwig wrote:

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

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

Re: EVMS Submission for 2.5

[Kevin Corry]

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

Re: EVMS Submission for 2.5

[Alan Cox]

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. 

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

[Kevin Corry]

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
corryk@us.ibm.com
http://evms.sourceforge.net/

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

[Kai Henningsen]

corryk@us.ibm.com (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