Re: Fully loadable device drivers

[Olaf Buddenhagen]

Hi,

On Mon, Oct 03, 2016 at 02:09:40PM +0300,  
??  wrote:

> Sorry, maybe I'm posting to wrong mailing list..

Probably. L4 never had in-kernel device drivers -- nor did any of the
other options that were being stipulated here. In fact this list has
been out of commission for a long time. bug-hurd is the right list for
this kind of discussion.

> I can't get the reason why Hurd development chose the way of compiling
> drivers with the kernel, same as linux.

Nobody actually *chose* this -- it's just what was inherited with the
Mach legacy. We want userspace drivers going forward, and indeed we
already have them for network devices. It just needs to be done for
other device classes. Wanna help? :-P

> It looks like an another boring buisness trick of foundations.

Err, what?

> if drivers would be totally independent from the kernel,

They can't be totally independent. They can (and should) run in separate
processes, though.

-antrik-

PS. Please don't send HTML mail.

Re: behavior of NO SENDERS notifications when receive rights move

[Kalle Olavi Niemitalo]

"Brent W. Baccala"  writes:

> Now I'm wondering - how would DEAD NAME notifications be handled?  rpctrace
> would want to transfer send rights with the DN notifications attached (so
> it could wrap them both), but my experience, and my understanding of the
> Mach documentation, is that moving a send right with a DN request triggers
> a PORT DELETED notification, which is not what we would want.

Before rpctrace moves the send right from the target task, it
could call mach_port_request_notification to cancel the dead-name
notification request.  This call returns the send-once right to
which the notification would have been sent.  After rpctrace has
moved the rights, it could restore the notification request,
now with a wrapped send right and a wrapped send-once right.

> We could swap the ports all around with the target
> task halted, and I'm not sure what would happen then.

Yes, I think attaching to a live task would require suspending
the task first.

Detaching from a live task seems harder.  If the target task has
a receive right to a wrapper port to which rpctrace has forwarded
messages from an original port, but the target task has not read
those messages, then rpctrace would have to requeue them to the
original port, but it seems difficult to preserve the original
order of messages if other tasks are simultaneously sending more
messages to the original port.  This might be solved by adding a
kernel function that requeues the messages, or by implementing a
MACH_SEND_LIFO option for mach_msg.  However, strace with system
call tracing would avoid this as well as other problems.