[lkml]   [2005]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] relayfs redux for 2.6.10: lean and mean

    Greg KH wrote:
    > Are they willing to trade off the performance of LTT to get this? I
    > thought this was being touted as a "when you need to test" type of
    > thing, not a "run it all the time" type of feature.

    The problem is that you never know beforehand when you're going to
    get that weird glitch on your server, or how much time you're going
    to need to reproduce it. People who manage thousands of servers
    will want to be able to fire this off at will without having to
    reboot/recompile their kernel. What has to be done is make the cost
    of the tracing infrastructure as minimal as possible when it is
    indeed built into the kernel (of course if it's disabled it should
    cost the same thing as if it wasn't there to boot: nothing.) This,
    though, is a separate topic which is being addressed in other threads.
    Have a look at Werner's resent postings if you're interested on the
    "[RFC] instrumentation" thread.

    > And a driver will never want to have both a relay channel, and a simple
    > debug output at the same time? You are now requiring them to look for
    > that data in two different points in the fs.
    > So, since you are proposing that relayfs be mounted all the time, where
    > do you want to mount it at? I had to provide a "standard" location for
    > debugfs for people to be happy with it, and the same issue comes up
    > here.
    > Also, why not export your relayfs ops so that someone useing debugfs can
    > create a relay channel in it, or in any other type of fs they might
    > create?

    Ok, there are a couple of things in there:

    - First I don't object to having the relayfs ops being exported so that
    they could be used in conjunction with other filesystems, in addition
    to having relayfs live as an independent fs. So as in the case above, we
    should be able to accomodate the device driver writer who wants to have
    all his files in the same fs. However, for the first case relayfs was
    built for, I think there is merit for having it live as a separate fs.
    Is this a good compromise for you?

    - As for where relayfs should be mounted, then this is a very good
    question. We've taken to the habit of having a /relayfs. If this is
    too problematic, I don't see any problem with /mnt/relayfs also. In
    either case, I have to admit frankly that I'm not familiar with the
    exact formal rules for introducing something like this. Of course
    I'm aware of the FHS and LSB, but let me know what you think is the
    best way to proceed here.


    Author, Speaker, Developer, Consultant
    Pushing Embedded and Real-Time Linux Systems Beyond the Limits || || 1-866-677-4546
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.022 / U:68.432 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site