l4-hurd
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]