> > The real solution is to add a real keyboard (and ps2) driver to oskit.
> Are we planning on having user-space drivers at some point? Wouldn't it
> be more Hurdish to have this stuff in user-space eventually (especially
> if we move to L4) ?
As usual, Marcus beat me to the punch. But the an
On Thu, Oct 18, 2001 at 04:28:51PM -0500, Kevin Kreamer wrote:
> > The real solution is to add a real keyboard (and ps2) driver to oskit.
> Are we planning on having user-space drivers at some point? Wouldn't it
> be more Hurdish to have this stuff in user-space eventually (especially
> if we mo
On Thu, Oct 18, 2001 at 03:36:41PM -0400, Roland McGrath said:
> That may be a good interim kludge, but I am not going to include it.
Ok.
[snip]
> The real solution is to add a real keyboard (and ps2) driver to oskit.
Are we planning on having user-space drivers at some point? Wouldn't it
be mo
Hello,
$ settrans -afg shadow shadowfs $PWD
(yes, in this case, it should be possible to cd
shadow/shadow/shadow...)
The problem was that shadowfs had the root node 'shadow' looked while
it also tried to _lookup_ the root node 'shadow' - result: deadlock.
The root node was different then all
That may be a good interim kludge, but I am not going to include it.
A better interim kludge would be to give oskit-mach a cheezy "kbd" device
that sets DC_RAW while it's open and resets it when it's closed. Then you
would use that instead of "console" as the device to read scancodes from.
When
> In German you would say that I have tomatoes on my eyes. ;)
You mean egg on your face? :-)
> Mmh. What about i386_io_perm_modify vs. task_terminate on SMP? I don't
> want to scribble in deallocated pages.
Hmm, yes. I think you want to task_lock while diddling it and check
TASK->active (l
On Thu, Oct 18, 2001 at 01:57:33PM +0200, Marcus Brinkmann wrote:
> Mmh. What about i386_io_perm_modify vs. task_terminate on SMP?
Giving the answer myself: A task_terminate terminates all threads before it
deallocates the task.
> Also, what about i386_io_perm_modify vs another cpu switching to
On Thu, Oct 18, 2001 at 01:57:33PM +0200, Marcus Brinkmann wrote:
> I think keeping the bitmap around at the risk that it is not used anymore is
> better than the risk that io_permissions are often switched and you end up
> allocatin and freeing often. For both cases it is true that they probably
Here is a patch enable setting DC_RAW via a device_set_status on the
console device. While doing this code, I found that devio.c in
hurd/daemons calls this function with the TTY_* flavors, hence their
inclusion here.
No changelog yet, as I am not sure how done I am. I'll continue
working on t
On Wed, Oct 17, 2001 at 04:43:55AM -0400, Roland McGrath wrote:
> > There are some details about the implementation which are not ideal, but ok:
> > Once a task gets a bitmap, it is never destroyed, even if no I/O ports are
> > enabled (all bits set). The bitmap is destroyed only with the task.
>
> I just want to know what is the primary thing to debug, or develop in Hurd.
> I ear that we have to implement pthreads, a fs for hurd, and a few things, but what
>is hte priority ?
If you follow this link[1], you will find the task and the todo
lists. They are generally up to date.
As for w
Hi list,
I just want to know what is the primary thing to debug, or develop in Hurd.
I ear that we have to implement pthreads, a fs for hurd, and a few things, but what is
hte priority ?
Thanks
--
Seb - [EMAIL PROTECTED]
Kernel is like sex, it' better when it's free.
GNU/Hurd, free t
12 matches
Mail list logo
