[lkml]   [2001]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] init/main.c/root_dev_names - another one #ifdef
On Oct 31, 2001  19:31 +0100, Christoph Hellwig wrote:
> On Wed, Oct 31, 2001 at 11:20:55AM -0700, Andreas Dilger wrote:
> > This seems kind of ugly - an array holding each device name? The patch
> > I have rather puts a function to generate the device names when needed
> > (which is probably not very often, unless GFS does something wierd).
> *nod*
> > I take it your patch is only the "bare bones" part which shows what is
> > changed?
> Well, it's a patch that tries to be not intrusive, it just crates the hooks
> the two blockdevice drivers in the OpenGFS tree can use.

Well, given that it's intrusive enough to change the gendisk struct
(which my patch does as well), we may as well go whole hog and remove
all of the partition name cruft from where it should not be. I suppose
the issue is whether you are expecting GFS to go into the kernel, or if
you want to keep the diff as small as possible if it will be outside
the kernel for a long time.

The LVM code had a global function to fix the naming issue for LVM
devices in /proc/partitions, but Linus (AFAIK) didn't like it because
it didn't fix the real problem, as the posted patch does, of localizing
the partition name generation to the driver itself. The only wart in
the current system is that we use an external buffer passed into the
driver, and if the driver likes long names (ala LVM) it will overflow.

As I look through the kernel today, there is even more ugliness spread
around with "#ifdef CONFIG_DEVFS" to create strange partition names in
places where it should probably not be.

Cheers, Andreas
Andreas Dilger

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.096 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site