lkml.org 
[lkml]   [2001]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace


    On Sat, 19 May 2001, Andrew Clausen wrote:

    > Alexander Viro wrote:
    > > 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 ;-)
    > >
    > > ioctls are even more evil than encoding limits into the name.
    >
    > Why? Encoding sounds funky... you don't get normal
    > ls behaviour, etc.

    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.

    > 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. I'd rather see
    trivial partitioning tools that consist only of UI code in case
    of Linux.

    > 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.

    > Libtool & friends deals with version skew (ugly, but it works...)

    With statically linked binaries? How?

    > 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.

    OK, let me put it that way: I know how to do it in the kernel with
    no code duplication and less impact on userland. 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.

    -
    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/

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