[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Importing LibC Functionality
From: |
wgrim |
Subject: |
Re: Importing LibC Functionality |
Date: |
Mon, 18 Jul 2005 13:15:17 -0500 |
User-agent: |
Internet Messaging Program (IMP) 3.2.6 |
Quoting Matthieu Lemerre <address@hidden>:
> address@hidden writes:
>
> Hi,
>
> > I'm new to GNU/Hurd on L4 (and in general), and I plan to implement a
> device
> > driver framework so that real system usability can start to occur while
> other
> > things are improved by other developers. I'm considering the deva/fabrica
> and
> > antrik proposals and don't currently have my own proposal or a design plan.
> >
> > However, I was wondering how difficult it is to import libc functionality
> into
> > GNU/Hurd? For example, let's say I didn't have "fread(3)", I'd have to
> import
> > that into GNU/Hurd's libc for my use. Also, I assume porting libc
> > functionality from GNU/Hurd on Mach would be the best option?
> >
> > Thanks so much in advance,
> > William (AKA Mike) Grim
>
> This is great. You may want to check out the fabrica module on cvs
> (cvs -z3 -d:ext:address@hidden:/cvsroot/hurd co fabrica),
> which already implements part of it. In particuliar, there are already
> libc functions ported from libc (maybe it's not complete, in which
> case you could take the one in the hurd-l4 module).
Great, I'll check out the fabrica module this evening and see what is already
in it.
> But I doubt you want to use fread or such high level operations in the
> device driver framework; the tasks in the device driver framework
> (device drivers, bus drivers, and others) should communicate with
> regular RPCs, and tasks outside the device driver framework would
> communicate with deva using RPCs like "open", "read", "write"
> (replacing the corresponding UNIX system calls).
Yeah, I didn't actually mean I'd implement such high-level functions; I was
merely using it as a poor example.
> Well, unless you want
> to implement antrik's proposal, in which case I can't help you.
I don't think I'm going to implement antrik's proposal the way he wants, but I
do have the idea in my head that a translator could offer the functionality he
wants (mapping device memory onto a file node). Though, I need to read his
proposal more carefully; I liked the requirements, just not the design.
> So I think most of the libc parts you want are for string operations;
> for threading, you have libpthread (I have seen there was a libfthread
> in the fabrica module, maybe this is lightweight threads? and so maybe
> you should use this instead.)
Okay, I'll take a look at the APIs for those and see how they work.
> Thanks,
> Matthieu
>
Thanks a lot for the input!
--Mike Grim
PS: I have it setup right now so I only get mailing list digests; responding to
me as well is currently the best idea.
-------------------------------------------------
SIUE Web Mail