EVMS Submission for 2.5

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

[Kevin Corry]

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

Re: EVMS Submission for 2.5

[Alexander Viro]

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.

Re: EVMS Submission for 2.5

[Shawn]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: EVMS Submission for 2.5

[Shawn]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

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

--
Shawn Leas
core@enodev.com

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: EVMS Submission for 2.5

[Greg KH]

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

Re: EVMS Submission for 2.5

[Alexander Viro]

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?

Re: EVMS Submission for 2.5

[Kevin Corry]

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

Re: EVMS Submission for 2.5

[Kevin Corry]

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

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 Submission for 2.5

[Alexander Viro]

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

Re: EVMS Submission for 2.5

[Kevin Corry]

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

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

[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 Submission for 2.5

[Alexander Viro]

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.

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

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

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 Submission for 2.5

[Linus Torvalds]

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

Re: EVMS Submission for 2.5

[Patrick Mochel]

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

Re: EVMS Submission for 2.5

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

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 <greg@kroah.com>
> To: Alexander Viro <viro@math.psu.edu>
> Cc: Kevin Corry <corryk@us.ibm.com>, linux-kernel@vger.kernel.org,
>      evms-devel@lists.sourceforge.net, torvalds@transmeta.com
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: EVMS Submission for 2.5

[Greg KH]

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

Re: EVMS Submission for 2.5

[Linus Torvalds]

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

Go wild.

		Linus

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

[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 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 Submission for 2.5

[Kevin Corry]

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

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 Submission for 2.5

[Greg KH]

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

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

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