DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Userland: suggestion for the userapi code


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Jul 2003 10:22:11 -0700 (PDT)

:In the userapi example you have:
:
:ssize_t
:read(int fd, void *buf, size_t bytes)
:{
:    SysReadMsg msg;
:
:    initSysReadMsg(&msg, &_sysreplyport, fd, buf, bytes);
:    error = _syscallport->mp_SendMsg(syscallport, &msg);
:    if (error == EASYNC) {
:        error = waitmsg(&msg);
:        ... blocks ...
:    }
:    errno = error;
:    return(msg.retcode);
:}
:
:I think there would be more flexibility with:
:
:ssize_t
:read(int fd, void *buf, size_t bytes)
:{
:    SysReadMsg msg;
:    SysMsgPort *port, *reply; /* or whatever */
:
:    ... check that fd is valid ...
:    port = _fdtab[fd].messagePort;
:    reply = _fdtab[fd].replyPort;
:
:    initSysReadMsg(&msg, reply, fd, buf, bytes);
:    error = port->mp_SendMsg(port, &msg);
:    if (error == EASYNC) {
:        error = reply->waitmsg(&msg);
:        ... blocks ...
:    }
:    errno = error;
:    return(msg.retcode);
:}
:
:Most of the time the per-fd ports are the system ports.
:
:This doesn't require any change in the kernel, but it makes user-level
:layering a lot easier... you could test and implement pseudo-devices
:as an _unprivileged_ user by wrapping open() or you could shortcut
:implementations of things like /dev/null or /dev/zero so they made
:no kernel crossings at all.
:
:(I hope this doesn't come out in HTML, NewsFlash doesn't seem to have
:a way to say "no, I don't bloody want rich text, I don't care how cool
:it is"... I need a better newsreader for Mac OS X. I wish TRN had
:multiple server support)

    Ah, the first rule of writing examples into web pages:  They become
    instantly obsolete.

    In fact the proper 'reply' port is likely going to be built into the
    thread structure, e.g.  &curthread->td_replyPort or something like
    that (the usermode equivalent, that is).  We probably do not want
    to associate the reply port with the descriptor, because the reply
    port really has nothing to do with the descriptor and everything to do
    with whoever is sending the message.

    I agree with in regards to storing the target port as part of the
    FD array.  Some care must be taken with anything descriptor based
    because the dynamic ELF loader itself (ld.so) will have to be able 
    to work with it, but the target port will wind up being the 'real'
    descriptor here I wager.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]