[lkml]   [2008]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: sysfs: tagged directories not merged completely yet
    Hello, Greg.

    Greg KH wrote:
    > On Tue, Oct 07, 2008 at 01:27:17AM -0700, Eric W. Biederman wrote:
    >> Unless someone will give an example of how having multiple superblocks
    >> sharing inodes is a problem in practice for sysfs and call it good
    >> for 2.6.28. Certainly it shouldn't be an issue if the network namespace
    >> code is compiled out. And it should greatly improve testing of the
    >> network namespace to at least have access to sysfs.
    > But if the network namespace code is in? THen we have problems, right?
    > And that's the whole point here.
    > The fact that you are trying to limit userspace view of in-kernel data
    > structures, based on that specific user, is, in my opinion, crazy.

    Well, that's the whole point of all the namespace stuff. If we're
    gonna do namespaces, view of in-kernel data structures need to be
    limited and modified one way or the other.

    > Why not just keep all users from seeing sysfs, and then have a user
    > daemon doing something on top of FUSE if you really want to see this
    > kind of stuff.

    That sounds nice. Out of ignorance, how is the /proc dealt with?
    Maybe we can have some unified approach for this multiple views of the
    system stuff.

    > The "leakage" just seems too hard to stop.
    >> Later Tejun or I or possibly someone else who cares can go back
    >> and simplify the sysfs locking to remove the need for multiple
    >> superblocks sharing inodes, and to address the other big nasties in
    >> the current sysfs implementation.
    > I know how the whole "we'll go back later and fix it up" stuff works,
    > I've used that excuse too many times in the past myself. Never happens
    > :)

    Heh... I've been telling Jeff I would update libata API doc right
    after the next big change for about two years now. :-)

    >> Greg I agree with Al that sysfs isn't perfect but we sure aren't going
    >> to fix it if you keep dropping or taking years to merge every patch
    >> from the people working on it, and then dropping those patches because
    >> someone frowns at them.
    > "years"? Come on, these did take a while due to travel and other stuff.
    > These are core kernel changes, and need time to ensure that they work
    > properly, and get the proper review from people who understand this kind
    > of stuff.

    Eric has tried hard for quite some time to improve sysfs and get the
    namespace stuff merged and it hasn't been a smooth process and mostly
    for non-technical reasons at that (his changes crashing with mine and
    me being lazy played a big part). So, now everything seemed to go in
    and got dropped again, so I think he has good reasons to get
    frustrated, so it would be really nice if we can discuss this with
    some civility.

    > And to call Al a generic "someone", is just rude and disrespectful. I
    > trust his opinion in this area far more than I do yours, to be honest.

    Al's review was very helpful but it wasn't the most respectful one
    either. I understand that's his style and you do too, right? Then, I
    don't think it's fair to call Eric rude and disrepectful for calling
    Al a generic "someone". Let's let that be his style too.

    > This whole series is dropped, if you want to resubmit them, feel free
    > to, _after_ adressing his issues.

    I think the more important thing to discuss is how this namespace
    stuff is gonna proceed. I'm quite ignorant about the issue and one of
    the reasons why I acked the changes although I had my reservations was
    becuase the namespace approach seemed to have been agreed upon. Is
    it? Can somebody hammer the big picture regarding namespaces into my
    small head?



     \ /
      Last update: 2008-10-08 01:39    [W:0.025 / U:46.088 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site