[lkml]   [2003]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Syscall numbers for BProc
    On Sat, Apr 05, 2003 at 01:15:37PM -0700, wrote:
    > The reason it is the way it is because when I'm trying to avoid
    > stomping on other syscalls, having a small foot print is a good thing.

    Adding more syscalls isn't really a big deal - whether you add one or
    a bunch of them in a diff doesn't really matter.

    > Breaking out every call into a separate syscall number would also make
    > it more difficult to add new features in the future.

    Which is a good thing :) Having syscall multiplexers leads to very
    messy APIs like the one you proposed :)

    > Since our nodes are running *nothing* but the Bproc slave, you can't
    > log in some other way to kill the slave and then reboot and you can't
    > run shutdown -r or something like that becuase there are no init
    > scripts.

    We have a reboot notifier call chain in the kernel.

    > > Should be read() on a special file.
    > It started life like that but then I liked the idea of being able to
    > do it from any node in the system. (remember no shared fs)

    You have this no shared fs argument a few times - why don't you _add_
    a shared virtual filesystem for kerne, information? This would clean
    up many of the messier APIs.

    > > I'm pretty sure this would better be a /proc/<pid>/image file you
    > > can read from.
    > I'm a little fuzzy on what you mean here. If you're suggesting that a
    > process read from its own /proc/pid/image, then that's hard because
    > the process is changing while you do it. In the 3rd party case (which
    > vmadump doesn't support) it gets more tricky because you need to make
    > sure the process is stopped and the CPU state stored while you're
    > reading this.

    Okay, you're right - this should be a syscall.

    > VMADump doesn't depend on BProc at all. You will, however, need a
    > system call for it the way it's written now :)

    Yeah, conviencded. Care to submit a separated out vmadump aptch with
    the syscalls for 2.5?

    > > > 0x1030 - VMAD_LIB_CLEAR - clear the library list
    > > > no arguments
    > >
    > > What library lists are all those calls about? Needs more explanation.
    > If you look at the virtual memory space of a dynamically linked
    > program, the percentage of space used by the program itself (i.e. not
    > libraries) is often very small. In an effort to make process
    > migration really cheap, we're willing to say that files X, Y and Z are
    > available on the machine where we'll be restoring the process image.
    > The candidates for remote caching are, obviously, large shared
    > libraries.
    > So, the dumper needs to know what it can expect to find on the remote
    > system and what it can't. That's where the library list comes in. It
    > probably should just be called the remote file list or something.
    > It's a gross hack where we tell the kernel code what it doesn't need
    > to dump. Anything that isn't dumped gets stored in the dump file as a
    > reference to a file. (e.g. map X bytes of /lib/ @ offset
    > Y)
    > And yeah, this might be cleaner as a writable special file but this
    > was easy given the big syscall mux.

    I don't think you really want a device for this. It's more an attribute
    of the mapping, so a MAP_ALWAYS_LOCAL flag to mmap sounds like the right

    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 13:34    [W:0.023 / U:22.924 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site