Alexander Viro wrote:
> ioctls are evil, period. At least with these names you can use normal
> scripting and don't need any special tools. Every ioctl means a binary
> that has no business to exist.
Special names are butt-ugly.
ioctl's can be replaced with games on /proc or whatever, which are
better than special names.
> > 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?
>
> It needs to read them. Writing doesn't add much.
Wrong. When you read, you throw out 90% of the useless crap.
When you write, you need to know about it, and provide
interfaces for it.
> I'd rather see
> trivial partitioning tools that consist only of UI code in case
> of Linux.
Some stuff friendly partition tools should have, IMHO:
(1) ability to predict what's going to happen. That way, you can
play around until it looks nice, and hit the friendly commit
button.
(2) ability to do data recovery (eg: probe for signatures where
it expects the start of partitions to occur. You can be
intelligent/quick about it, by knowing about alignment stuff,
for example)
(3) ability to convert between partition table types (and
even LVM ;-) This can be tricky because of alignment stuff.
So:
(1) could be done in-kernel by being able to discard changes,
and re-reading, I guess.
(2) and (3) really only need alignment stuff.
Also, you need to be able to deal with legacy stuff, like
setting magic flags for booting.
> > 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.
>
> So don't communicate them.
So, what do you do?
Sometimes, you want to force alignment violations (eg: recovering
an accidently deleted partition)
The real problem happens when you want to resize file systems, and
you need to simultaneously satisfy resizer and partition table
constraints. (there are currently no resizers like this, but
an ext2-resize-the-start and NTFS-resize-the-start would definitely
be like this... when I get time to write them. It's pure luck
that you don't need this for FAT, but this causes all sorts of
headaches for Linux...)
Anyway, you have one constraint in user space, and one in the
kernel... how do you find the intersection?
> > Libtool & friends deals with version skew (ugly, but it works...)
>
> With statically linked binaries? How?
Why do we need them?
> > You can write wrappers for libraries.
>
> Uh-huh. And you can write them for ioctls. We had been busily doing that
> for years. Results are not pretty, to put it very mildly.
If you can get everything into a nice file system interface,
then you've convinced me.
> BTW, most of the
> code can very well sit in the userland, but that's another story
> (userland filesystems). Anyway, there's only one way to settle such
> stuff - sit down and write the patch. Which is what I'm going to do.
Have fun.
So, my patch will be about 50 lines in parted, to call blkpg,
and provide a "kernelread" command... But, philosophy essay to
write... :-( (you have to wait until Monday)
Then you can rm -r fs/partitions
But, I don't see how patches will settle anything, when we're
arguing over interfaces & stuff needed for partition tools. Or
are you writing patches for Parted as well?
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/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:32 EST