Why? Encoding sounds funky... you don't get normal
ls behaviour, etc.
I think I'd prefer something like /dev/hda/table, where
table is something like /proc/partitions for /dev/hda, but
it's read/write ;-)
> Cease and desist, please.
Hehe
> > (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>
>
> We will be much better off providing a sane API from the kernel. And
> dropping the layout-aware code from fdisk, parted, yodda, yodda.
What about partition editing on other OSs? There's no reason
why fdisk/parted/etc. should be Linux only. Why should the kernel
need to know how to write partition tables?
Also, different partition table formats have different alignment
constraints (which is relevant for creating partitions). These
mainly need to be respected for other braindead OS's and/or BIOSes.
Communicating those between user/kernel space doesn't excite me.
Any ideas?
> Libraries do not remove code duplication. You still need to relink the
> stuff you keep statically linked, etc. Otherwise you get version skew.
> Big way. Besides, you can't use library from a script, etc.
Libtool & friends deals with version skew (ugly, but it works...)
You can write wrappers for libraries.
That said, a kernel API would be nice, if it was doable...
Andrew Clausen
-
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/