Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
>> What is the communication between user space and kernel >> that transports device identities? > It doesn't change, the same symbolic names still work. But today, unless you think of devfs or so, device identities are not transported by symbolic names. They are given by device numbers. [Yes, symbolic names have a certain secondary role, e.g. in error messages, or perhaps to indicate the boot device.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 14:43, [EMAIL PROTECTED] wrote: > How about: > > # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap > # ls /dev/mypartition > basesizedevicetype > > Generally, we shouldn't care which order the kernel enumerates > devices in or which device number gets assigned internally. If > we did need to care, we'd just do: > > # echo 666 >/dev/mypartition/number > > Only a single thing is of interest. > What is the communication between user space and kernel > that transports device identities? It doesn't change, the same symbolic names still work. What's happening in my example is, we've gotten rid of the can't-get-there-from-here device naming heirarchy. It should be clear by now that we can't capture 'physical device location' and 'device function' in one tree. So instead, 'physical device' is a property of 'logical device'. The tree is now optional. > Note that there is user (human) / user space (programs) / kernel. > > This user has interesting machinery in his hands, > but his programs have only strings (path names, fake or not) > to give to the kernel in open() and mount() calls. > > Now the device path is so complicated that the user is unable to > describe it using a path name. devfs made an attempt listing > controller, lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is > not very attractive, and things only get worse. Yes, we flatten that by making host, bus, target and lun all properties of /proc/ide/hda. Our mistake up to now is that we've tried to carry the logical view and physical view of the device in one name, or equivalently, in path+name. Let the physical device be a property of the logical device and we no longer have our thumb tied to our nose. > When I go to a bookshop to buy a book, I can do so without specifying > all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, > ... A few items suffice. Often the Title alone will do. > > We want an interface where the kernel exports what it has to offer > and the user can pick. Yes, that Zip drive - never mind the bus. > But can distinguish - Yes, that USB Zip drive, not the one > on the parallel port. 100% agreed. IOW, when the device *does* move we can usually deduce where it's moved to, so lets update the hda's bus location automatically whenever we can (log a message!) and only bother the user about it if it's ambiguous. For good measure, have a system setting that says 'on a scale of 0 to 5, this is how interested I am in being bothered about the fact that a device seems to have moved'. > The five minute hack would number devices 1, 2, 3 in order of > detection, offer the detection message in > /devices//detectionmessage and a corresponding device node in > /devices//devicenode. The sysadmin figures out what is what, > makes a collection of symlinks with his favorite names, and everybody > is happy. > > Until the next reboot. Or until device removal and addition. > There must be a way to give permanence to an association > between name and device. Symlinks into a virtual filesystem > like /devices are not good enough. Turning the five minute > hack into a ten minute hack we take the md5sum of the part > of the bootmessage that is expected to be the same the next time > we encounter this device and use that as device number. > > I think a system somewhat in this style could be made to work well. Yes, we are advocating the same thing. I didn't mention that the device properties are supposed to be persistent, did I? If you accept the idea of persistent device properties then the obvious thing to do is to match them up against the detected devices. I didn't want to bring up the persistency thing right away because it begs the question of where you store the persistent data for the root device. Until the namespace issue is resolved this is mainly a distraction. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 10:14, Lars Marowsky-Bree wrote: > On 2001-05-19T16:25:47, > >Daniel Phillips <[EMAIL PROTECTED]> said: > > How about: > > > > # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap > > # ls /dev/mypartition > > base sizedevice type > > # cat /dev/mypartition/size > > 1048576 > > # cat /dev/mypartition/device > > /dev/sda > > # mke2fs /dev/mypartition > > Ek. You want to run mke2fs on a _directory_ ? Could you be specific about what is wrong with that? Assuming that this device directory lives on a special purpose filesystem? > If anything, /dev/mypartition/realdev Then every fstab in the world has to change, not to mention adding verbosity to interactive commands. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
What is the communication between user space and kernel that transports device identities? It doesn't change, the same symbolic names still work. But today, unless you think of devfs or so, device identities are not transported by symbolic names. They are given by device numbers. [Yes, symbolic names have a certain secondary role, e.g. in error messages, or perhaps to indicate the boot device.] Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 14:43, [EMAIL PROTECTED] wrote: How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition basesizedevicetype Generally, we shouldn't care which order the kernel enumerates devices in or which device number gets assigned internally. If we did need to care, we'd just do: # echo 666 /dev/mypartition/number Only a single thing is of interest. What is the communication between user space and kernel that transports device identities? It doesn't change, the same symbolic names still work. What's happening in my example is, we've gotten rid of the can't-get-there-from-here device naming heirarchy. It should be clear by now that we can't capture 'physical device location' and 'device function' in one tree. So instead, 'physical device' is a property of 'logical device'. The tree is now optional. Note that there is user (human) / user space (programs) / kernel. This user has interesting machinery in his hands, but his programs have only strings (path names, fake or not) to give to the kernel in open() and mount() calls. Now the device path is so complicated that the user is unable to describe it using a path name. devfs made an attempt listing controller, lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is not very attractive, and things only get worse. Yes, we flatten that by making host, bus, target and lun all properties of /proc/ide/hda. Our mistake up to now is that we've tried to carry the logical view and physical view of the device in one name, or equivalently, in path+name. Let the physical device be a property of the logical device and we no longer have our thumb tied to our nose. When I go to a bookshop to buy a book, I can do so without specifying all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, ... A few items suffice. Often the Title alone will do. We want an interface where the kernel exports what it has to offer and the user can pick. Yes, that Zip drive - never mind the bus. But can distinguish - Yes, that USB Zip drive, not the one on the parallel port. 100% agreed. IOW, when the device *does* move we can usually deduce where it's moved to, so lets update the hda's bus location automatically whenever we can (log a message!) and only bother the user about it if it's ambiguous. For good measure, have a system setting that says 'on a scale of 0 to 5, this is how interested I am in being bothered about the fact that a device seems to have moved'. The five minute hack would number devices 1, 2, 3 in order of detection, offer the detection message in /devices/nr/detectionmessage and a corresponding device node in /devices/nr/devicenode. The sysadmin figures out what is what, makes a collection of symlinks with his favorite names, and everybody is happy. Until the next reboot. Or until device removal and addition. There must be a way to give permanence to an association between name and device. Symlinks into a virtual filesystem like /devices are not good enough. Turning the five minute hack into a ten minute hack we take the md5sum of the part of the bootmessage that is expected to be the same the next time we encounter this device and use that as device number. I think a system somewhat in this style could be made to work well. Yes, we are advocating the same thing. I didn't mention that the device properties are supposed to be persistent, did I? If you accept the idea of persistent device properties then the obvious thing to do is to match them up against the detected devices. I didn't want to bring up the persistency thing right away because it begs the question of where you store the persistent data for the root device. Until the namespace issue is resolved this is mainly a distraction. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 10:14, Lars Marowsky-Bree wrote: On 2001-05-19T16:25:47, Daniel Phillips [EMAIL PROTECTED] said: How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition base sizedevice type # cat /dev/mypartition/size 1048576 # cat /dev/mypartition/device /dev/sda # mke2fs /dev/mypartition Ek. You want to run mke2fs on a _directory_ ? Could you be specific about what is wrong with that? Assuming that this device directory lives on a special purpose filesystem? If anything, /dev/mypartition/realdev Then every fstab in the world has to change, not to mention adding verbosity to interactive commands. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition basesizedevicetype Generally, we shouldn't care which order the kernel enumerates devices in or which device number gets assigned internally. If we did need to care, we'd just do: # echo 666 >/dev/mypartition/number Only a single thing is of interest. What is the communication between user space and kernel that transports device identities? Note that there is user (human) / user space (programs) / kernel. This user has interesting machinery in his hands, but his programs have only strings (path names, fake or not) to give to the kernel in open() and mount() calls. Now the device path is so complicated that the user is unable to describe it using a path name. devfs made an attempt listing controller, lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is not very attractive, and things only get worse. When I go to a bookshop to buy a book, I can do so without specifying all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, ... A few items suffice. Often the Title alone will do. We want an interface where the kernel exports what it has to offer and the user can pick. Yes, that Zip drive - never mind the bus. But can distinguish - Yes, that USB Zip drive, not the one on the parallel port. The five minute hack would number devices 1, 2, 3 in order of detection, offer the detection message in /devices//detectionmessage and a corresponding device node in /devices//devicenode. The sysadmin figures out what is what, makes a collection of symlinks with his favorite names, and everybody is happy. Until the next reboot. Or until device removal and addition. There must be a way to give permanence to an association between name and device. Symlinks into a virtual filesystem like /devices are not good enough. Turning the five minute hack into a ten minute hack we take the md5sum of the part of the bootmessage that is expected to be the same the next time we encounter this device and use that as device number. I think a system somewhat in this style could be made to work well. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On 2001-05-19T16:25:47, Daniel Phillips <[EMAIL PROTECTED]> said: > How about: > > # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap > # ls /dev/mypartition > basesizedevice type > # cat /dev/mypartition/size > 1048576 > # cat /dev/mypartition/device > /dev/sda > # mke2fs /dev/mypartition Ek. You want to run mke2fs on a _directory_ ? If anything, /dev/mypartition/realdev Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Saturday 19 May 2001 08:23, Ben LaHaise wrote: > /dev/sda/offset=1024,limit=2048 > -> open a device that gives a view of sda at an > offset of 1KB to 2KB Whatever we end up with, can we express it in terms of base, size, please? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On 2001-05-19T16:25:47, Daniel Phillips [EMAIL PROTECTED] said: How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition basesizedevice type # cat /dev/mypartition/size 1048576 # cat /dev/mypartition/device /dev/sda # mke2fs /dev/mypartition Ek. You want to run mke2fs on a _directory_ ? If anything, /dev/mypartition/realdev Sincerely, Lars Marowsky-Brée [EMAIL PROTECTED] -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition basesizedevicetype Generally, we shouldn't care which order the kernel enumerates devices in or which device number gets assigned internally. If we did need to care, we'd just do: # echo 666 /dev/mypartition/number Only a single thing is of interest. What is the communication between user space and kernel that transports device identities? Note that there is user (human) / user space (programs) / kernel. This user has interesting machinery in his hands, but his programs have only strings (path names, fake or not) to give to the kernel in open() and mount() calls. Now the device path is so complicated that the user is unable to describe it using a path name. devfs made an attempt listing controller, lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is not very attractive, and things only get worse. When I go to a bookshop to buy a book, I can do so without specifying all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, ... A few items suffice. Often the Title alone will do. We want an interface where the kernel exports what it has to offer and the user can pick. Yes, that Zip drive - never mind the bus. But can distinguish - Yes, that USB Zip drive, not the one on the parallel port. The five minute hack would number devices 1, 2, 3 in order of detection, offer the detection message in /devices/nr/detectionmessage and a corresponding device node in /devices/nr/devicenode. The sysadmin figures out what is what, makes a collection of symlinks with his favorite names, and everybody is happy. Until the next reboot. Or until device removal and addition. There must be a way to give permanence to an association between name and device. Symlinks into a virtual filesystem like /devices are not good enough. Turning the five minute hack into a ten minute hack we take the md5sum of the part of the bootmessage that is expected to be the same the next time we encounter this device and use that as device number. I think a system somewhat in this style could be made to work well. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Saturday 19 May 2001 08:23, Ben LaHaise wrote: /dev/sda/offset=1024,limit=2048 - open a device that gives a view of sda at an offset of 1KB to 2KB Whatever we end up with, can we express it in terms of base, size, please? -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
[EMAIL PROTECTED] wrote:
>
> Hmm. You know that I wrote this long ago?
Well, let's not get too hung up on the disk thing (yeah,
I started it...).
Ben's intent here is to *demonstrate* how argv-style
info can be passed into device nodes. It seems neat,
and nice.
We can also make use of a strong argument parsing library
in the kernel - there are a great number of open-coded
string bashing functions which could be rationalised
and regularised.
So. When am I going to be able to:
open("/bin/ls,-l,/etc/passwd", O_RDONLY);
?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
Ben LaHaise <[EMAIL PROTECTED]> writes: > Hey folks, > > The work-in-progress patch for-demonstration-purposes-only below consists > of 3 major components, and is meant to start discussion about the future > direction of device naming and its interaction block layer. The main > motivations here are the wasting of minor numbers for partitions, and the > duplication of code between user and kernel space in areas such as > partition detection, uuid location, lvm setup, mount by label, journal > replay, and so on... > > 1. Generic lookup method and argument parsiing (fs/lookupargs.c) > > This code implements a lookup function which is for demonstration > purposes used in fs/block_dev.c. The general idea is to pass > additional parameters to device drivers on open via a comma > seperated list of options following the device's name. Sample > uses: > > /dev/sda/raw-> open sda in raw mode. > /dev/sda/limit=102400 -> open sda with a limit of 100K > /dev/sda/offset=1024,limit=2048 > -> open a device that gives a view of sda at an > offset of 1KB to 2KB GAhh!! Ben please think /proc/sys. One value per ``file''. > 3. Userspace partition code proposal > > Given the above two bits, here's a brief explaination of a > proposal to move management of the partitioning scheme into > userspace, along with portions of raid startup, lvm, uuid and > mount by label code needed for mounting the root filesystem. > > Consider that the device node currently known as /dev/hda5 can > also be viewed as /dev/hda at offset 512000 with a limit of 10GB. > With the extensions in fs/block_dev.c, you could replace /dev/hda5 > with /dev/hda/offset=512000,limit=1024000. Now, by putting > the partition parsing code into a libpart and binding mount to a > libpart, the root filesystem mounting code can be run out of an > initrd image. The use of mount gives us the ability to mount > filesystems by UUID, by label or other exotic schemes without > having to add any additional code to the kernel. But you need to use uclibc or a similar library to get the code size down small enough, so you don't quadruple the size of your boot image. As for wasting minors. If you are going to rework partitions they should have dynamic device numbers. That are assigned when the partition is discovered by the system. I admit a hot-plug partition sounds incongruous but it should be fairly simple to implement. If your real root is on a ``hot-plug'' device then it does look like you need an initrd to help select your root partition. Hmm. the code is simple enough code in the kernel shouldn't be bad. And the interface can be simple as well. Have: /dev/sda/partitions/1 /dev/sda/partitions/2 /dev/sda/partitions/3 /dev/sda/partitions/4 /dev/sda/partitions/5 and also /dev/sda/partitions/1/uuid /dev/sda/partitions/1/label /dev/sda/partitions/1/offset /dev/sda/partitions/1/limit To expose what the kernel found it's initial scan of the partitions. For creating partitions you might want to do: cat 1024 2048 > /dev/sda/newpartition Though if you could do it with create that would be nicer, and writes to offset and limit, that would be a little nicer. Al would it work to have the lookup method for /dev/sda automatically mount an instance of scsifs on /dev/hda (from an internal mount), and then have dput drop that mount. I skimmed the code and it looks possible. Soft mounting a fs isn't strictly necessary but for the case above but it looks simplest to keep the list of partitions permanently in the dcache. We would also need to modify permission to take a vfsmnt argument so your permissions to a device file could vary depending on which device file you start with. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
From: Ben LaHaise <[EMAIL PROTECTED]> 3. Userspace partition code proposal Given the above two bits, here's a brief explaination of a proposal to move management of the partitioning scheme into userspace, along with portions of raid startup, lvm, uuid and mount by label code needed for mounting the root filesystem. Consider that the device node currently known as /dev/hda5 can also be viewed as /dev/hda at offset 512000 with a limit of 10GB. With the extensions in fs/block_dev.c, you could replace /dev/hda5 with /dev/hda/offset=512000,limit=1024000. Now, by putting the partition parsing code into a libpart and binding mount to a libpart, the root filesystem mounting code can be run out of an initrd image. The use of mount gives us the ability to mount filesystems by UUID, by label or other exotic schemes without having to add any additional code to the kernel. I'm going to stop writing this now. I need sleep... Hmm. You know that I wrote this long ago? And that it has been part of the kernel for a long time? And that there are user space utilities that use it? In util-linux, look at the partx subdirectory. In the kernel, read drivers/block/blkpg.c. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
From: Ben LaHaise [EMAIL PROTECTED] 3. Userspace partition code proposal Given the above two bits, here's a brief explaination of a proposal to move management of the partitioning scheme into userspace, along with portions of raid startup, lvm, uuid and mount by label code needed for mounting the root filesystem. Consider that the device node currently known as /dev/hda5 can also be viewed as /dev/hda at offset 512000 with a limit of 10GB. With the extensions in fs/block_dev.c, you could replace /dev/hda5 with /dev/hda/offset=512000,limit=1024000. Now, by putting the partition parsing code into a libpart and binding mount to a libpart, the root filesystem mounting code can be run out of an initrd image. The use of mount gives us the ability to mount filesystems by UUID, by label or other exotic schemes without having to add any additional code to the kernel. I'm going to stop writing this now. I need sleep... Hmm. You know that I wrote this long ago? And that it has been part of the kernel for a long time? And that there are user space utilities that use it? In util-linux, look at the partx subdirectory. In the kernel, read drivers/block/blkpg.c. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
Ben LaHaise [EMAIL PROTECTED] writes: Hey folks, The work-in-progress patch for-demonstration-purposes-only below consists of 3 major components, and is meant to start discussion about the future direction of device naming and its interaction block layer. The main motivations here are the wasting of minor numbers for partitions, and the duplication of code between user and kernel space in areas such as partition detection, uuid location, lvm setup, mount by label, journal replay, and so on... 1. Generic lookup method and argument parsiing (fs/lookupargs.c) This code implements a lookup function which is for demonstration purposes used in fs/block_dev.c. The general idea is to pass additional parameters to device drivers on open via a comma seperated list of options following the device's name. Sample uses: /dev/sda/raw- open sda in raw mode. /dev/sda/limit=102400 - open sda with a limit of 100K /dev/sda/offset=1024,limit=2048 - open a device that gives a view of sda at an offset of 1KB to 2KB GAhh!! Ben please think /proc/sys. One value per ``file''. 3. Userspace partition code proposal Given the above two bits, here's a brief explaination of a proposal to move management of the partitioning scheme into userspace, along with portions of raid startup, lvm, uuid and mount by label code needed for mounting the root filesystem. Consider that the device node currently known as /dev/hda5 can also be viewed as /dev/hda at offset 512000 with a limit of 10GB. With the extensions in fs/block_dev.c, you could replace /dev/hda5 with /dev/hda/offset=512000,limit=1024000. Now, by putting the partition parsing code into a libpart and binding mount to a libpart, the root filesystem mounting code can be run out of an initrd image. The use of mount gives us the ability to mount filesystems by UUID, by label or other exotic schemes without having to add any additional code to the kernel. But you need to use uclibc or a similar library to get the code size down small enough, so you don't quadruple the size of your boot image. As for wasting minors. If you are going to rework partitions they should have dynamic device numbers. That are assigned when the partition is discovered by the system. I admit a hot-plug partition sounds incongruous but it should be fairly simple to implement. If your real root is on a ``hot-plug'' device then it does look like you need an initrd to help select your root partition. Hmm. the code is simple enough code in the kernel shouldn't be bad. And the interface can be simple as well. Have: /dev/sda/partitions/1 /dev/sda/partitions/2 /dev/sda/partitions/3 /dev/sda/partitions/4 /dev/sda/partitions/5 and also /dev/sda/partitions/1/uuid /dev/sda/partitions/1/label /dev/sda/partitions/1/offset /dev/sda/partitions/1/limit To expose what the kernel found it's initial scan of the partitions. For creating partitions you might want to do: cat 1024 2048 /dev/sda/newpartition Though if you could do it with create that would be nicer, and writes to offset and limit, that would be a little nicer. Al would it work to have the lookup method for /dev/sda automatically mount an instance of scsifs on /dev/hda (from an internal mount), and then have dput drop that mount. I skimmed the code and it looks possible. Soft mounting a fs isn't strictly necessary but for the case above but it looks simplest to keep the list of partitions permanently in the dcache. We would also need to modify permission to take a vfsmnt argument so your permissions to a device file could vary depending on which device file you start with. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
[EMAIL PROTECTED] wrote: Hmm. You know that I wrote this long ago? Well, let's not get too hung up on the disk thing (yeah, I started it...). Ben's intent here is to *demonstrate* how argv-style info can be passed into device nodes. It seems neat, and nice. We can also make use of a strong argument parsing library in the kernel - there are a great number of open-coded string bashing functions which could be rationalised and regularised. So. When am I going to be able to: open(/bin/ls,-l,/etc/passwd, O_RDONLY); ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
