Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Peter has already written device drivers for embedded Linux, and actually
> has a lot of experience on how to write device drivers portably (he is
> actually giving a talk at FOSDEM about it, he announced this on this list).
That's fine. Hurd require
On Thu, Feb 06, 2003 at 06:48:01PM +0100, Niels Möller wrote:
> I mean, one can start designing a framework and discuss for months
> what's the best way of organizing things (see the networking
> discussion we had a while back). And given the framework, one can
> start writing drivers. That approac
On Thu, Feb 06, 2003 at 08:11:47AM -0800, Jeff Bailey wrote:
> Of course it will, but that doesn't mean that the Hurd repository is the
> right place for them. Almost all of the code in the Hurd repository
> (with some notable exceptions, like some CMU code that's still around
> and the pfinet ser
On Thu, Feb 06, 2003 at 06:09:27PM +0100, Robert Millan wrote:
> On Mon, Feb 03, 2003 at 02:28:52PM +0100, Robert Millan wrote:
> > On Fri, Jan 31, 2003 at 09:08:40PM +0100, Marcus Brinkmann wrote:
> > >
> > > ioperm is supported in GNU Mach v2, that's what I implemented a year ago
> >
> > I trie
Robert Millan <[EMAIL PROTECTED]> writes:
> glad to hear. do you think it's pointful to implement it in Mach so we
> can use interrupts instead of polling from now on?
I haven't looked at all at Mach interrupt handling. If it's easy to
implement intwait (did I understand you correctly that intwai
On Thu, Feb 06, 2003 at 05:17:18PM +0100, Niels Möller wrote:
>
> Thinking about L4, I have no idea how ioperm should work, but intwait
> should be fairly easy to implement, it just needs to wait for a
> message from the kernel.
glad to hear. do you think it's pointful to implement it in Mach so
On Mon, Feb 03, 2003 at 02:28:52PM +0100, Robert Millan wrote:
> On Fri, Jan 31, 2003 at 09:08:40PM +0100, Marcus Brinkmann wrote:
> >
> > ioperm is supported in GNU Mach v2, that's what I implemented a year ago
>
> I tried on GNUMach 2 and it failed with errno "Function not implemented"..
looki
me an essential part
of the GNU system? because when the Hurd runs on L4, userspace drivers
will be essential.
--
Robert Millan
"Omnis enim res, quad dando non deficit, dum habetur et non datur,
nondum habetur, quomodo habenda est."
"For if a thing is not diminished by being shared with
. On the other hand, having
> > a sub project that deals with drivers and driver infrastracture would be
> > very worthwhile.
> do you mean the Hurd repository is not their place? when the Hurd runs on L4
> it will certainly need userspace drivers..
Of course it will, but that does
Robert Millan <[EMAIL PROTECTED]> writes:
> well, from my tiny experience on writing a parallel port driver i can say
> that userspace drivers for GNU are very portable. The only system resources
> one needs (besides Hurd's fs libraries of course) is a working ioperm(), w
On Thu, Feb 06, 2003 at 04:43:45PM +0100, Marcus Brinkmann wrote:
>
> You are aware of Peter Schrivjers intentions to write an L4 driver
> framework?
>
> The problem is not writing one parallel port driver, or even one nic driver.
> The problem is writing a good framework that allows a zillion of
r hand, having
> a sub project that deals with drivers and driver infrastracture would be
> very worthwhile.
do you mean the Hurd repository is not their place? when the Hurd runs on L4
it will certainly need userspace drivers..
> I would encourage you to work on it, and setup mail
On Thu, Feb 06, 2003 at 03:40:22PM +0100, Robert Millan wrote:
> is such work welcome then? i mean, if i write a decent driver will it be
> included in the Hurd now or in a later term?
> if there isn't interest at the moment i might consider creating a subproject
> at savan
> well end up throwing away upon a switch to another kernel.
well, from my tiny experience on writing a parallel port driver i can say
that userspace drivers for GNU are very portable. The only system resources
one needs (besides Hurd's fs libraries of course) is a working ioperm(), which
i
On Wed, Feb 05, 2003 at 03:06:17PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > The question of user interrupt handlers: There is an interface, but I don't
> > think it was ever tried in GNU Mach, so I don't know if that works or can be
> > resurrected.
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The question of user interrupt handlers: There is an interface, but I don't
> think it was ever tried in GNU Mach, so I don't know if that works or can be
> resurrected. In any case user space drivers are only interesting in a more
> modern microkern
On Fri, Jan 31, 2003 at 09:08:40PM +0100, Marcus Brinkmann wrote:
> On Fri, Jan 31, 2003 at 04:36:35PM +0100, Robert Millan wrote:
> > I've read the IO section and doesn't realy seem a useful interface. any plans
> > to provide ioperm ()?
>
> ioperm is supported in GNU Mach v2, that's what I imple
On Fri, Jan 31, 2003 at 04:36:35PM +0100, Robert Millan wrote:
> I've read the IO section and doesn't realy seem a useful interface. any plans
> to provide ioperm ()?
ioperm is supported in GNU Mach v2, that's what I implemented a year ago
(and I think it is in the GNU Mach manual, although I am n
On Tue, Jan 21, 2003 at 08:55:56AM +0100, Joachim Nilsson wrote:
> On Mon, Jan 20, 2003 at 11:25:14PM +0100, Robert Millan wrote:
> > On Mon, Jan 20, 2003 at 11:09:02AM -0800, James Morrison wrote:
> > > I don't believe any work is being done on userspace drivers. If
On Mon, Jan 20, 2003 at 11:25:14PM +0100, Robert Millan wrote:
> On Mon, Jan 20, 2003 at 11:09:02AM -0800, James Morrison wrote:
> > I don't believe any work is being done on userspace drivers. If you want to
> > look specifically mach user space drivers you can re
On Mon, Jan 20, 2003 at 11:09:02AM -0800, James Morrison wrote:
>
> I don't believe any work is being done on userspace drivers. If you want to
> look specifically mach user space drivers you can read the mach 3 Kernel
> Interface[1]. If you aren't specifically looking at
--- Robert Millan <[EMAIL PROTECTED]> wrote:
>
>
> Hi!
>
> I'd like to play a bit with userspace drivers, but i have some
> doubts on the interfaces:
>
> - how can i wait for a hardware interruption in a userspace process?
> - despite it's not nec
Hi!
I'd like to play a bit with userspace drivers, but i have some
doubts on the interfaces:
- how can i wait for a hardware interruption in a userspace process?
- despite it's not necessary due to a well-known bug, how
can i ask Mach for permission to access io ports?
also, is
23 matches
Mail list logo