Re: any chance we could dump the 64k subdirectory limit before 2.4 ships?

From: Alexander Viro (viro@math.psu.edu)
Date: Sat May 27 2000 - 08:29:38 EDT

  • Next message: Alan Cox: "Re: [KBUILD] Re: Announcing CML2, a replacement for the kbuild system"

    On Sat, 27 May 2000, Andries Brouwer wrote:

    > On Fri, May 26, 2000 at 09:07:58PM -0400, Alexander Viro wrote:
    >
    > > Look: there are other good reasons to change struct stat and I'm not too
    > > happy about doing it in $BIGNUM steps, each resulting in new triple of
    > > syscalls. If we are going to do that at all we'ld better do it at once.
    >
    > Yes, there are many reasons to change struct stat,
    > and it is unlikely that we can do it all at once.
    > But we only need 3 more syscalls once - they'll suffice forever.
    >
    > An old patch of mine (part of the "larger dev_t" suite) goes like
    > ...
    > +typedef int (*cp_stat_fn)(struct inode *, void *);
    [snip]

    Out of curiosity: what was Linus' reaction to that? 'Cause mine was to
    crawl into the dark corner silently muttering "it's hopelessly, completely
    wrong"... Damn, if we are going to go for something like that we'ld better
    switch to ASCII and be done with that. It isn't different from multiple
    syscalls - you are just passing the number through another register. All
    the difference is that you are inviting said $BIGNUM of variants, loud
    and clear. Moreover, it _still_ means changing the userland upon every
    round of that game. So... what does it buy us? Frankly, I'ld rather see
    the output in char * - yes, octal, space-separated, NUL-terminated ASCII
    string. I suspect that you will lose more cycles on selecting the version
    number compatible with the current kernel and shuffling the bits into
    places anyway...

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Sat May 27 2000 - 10:20:19 EDT