On Sat, 19 May 2001, Andrew Clausen wrote:
> (1) these issues are independent. The partition parsing could
> be done in user space, today, by blkpg, if I read the code correctly
> ;-) (there's an ioctl for [un]registering partitions) Never
> tried it though ;-)
I tried to imply that through the use of the the word component. Yes,
they're independant, but the code is pretty meaningless without a
demonstration of how it's used. ;-)
> (2) what about bootstrapping? how do you find the root device?
> Do you do "root=/dev/hda/offset=63,limit=1235823"? Bit nasty.
root= becomes a parameter to mount, and initrd becomes mandatory. I'd be
all for including all of the bits needed to build the initrd boot code in
the tree, but it's completely in the air.
> (3) how does this work for LVM and RAID?
It's not done yet, but similar techniques would be applied. I envision
that a raid device would support operations such as
open("/dev/md0/slot=5,hot-add=/dev/sda")
> (4) <propaganda>libparted already has a fair bit of partition
> scanning code, etc. Should be trivial to hack it up... That said,
> it should be split up into .so modules... 200k is a bit heavy just
> for mounting partitions (most of the bulk is file system stuff).
> </propaganda>
Good. Less work to do.
> (5) what happens to /etc/fstab? User-space ([u]mount?) translates
> /dev/hda1 into /dev/hda/offset=63,limit=1235823, and back?
I'd just create a symlink to /dev/hda1 at mount time, although that really
isn't what the user wants to see: the label or uuid is more useful.
-ben
-
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/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:32 EST