Oops! Thanks.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
The oskit_guid in your i8042 patch is already used by the socket
interface (oskit/net/socket.h).
#define OSKIT_STREAMDEV_IID OSKIT_GUID(0x4aa7dfad, 0x7c74, 0x11cf, \
0xb5, 0x00, 0x08, 0x00, 0x09, 0x53, 0xad, 0xc2)
#define OSKIT_SOCKET_IID OSKIT_GUID(0x4aa7dfad, 0x7c74, 0x11cf, \
D'oh! I was definitely confused there. I reverted the bumping of the ref
count. But I think you were still seeing problems here.
As to the device mode thing, it's definitely not quite right. The issue is
how much you want to avoid reopening the device at the COM layer,
i.e. calling the driver'
On Sun, Nov 10, 2002 at 02:05:20AM +0100, Marcus Brinkmann wrote:
> On Fri, Nov 08, 2002 at 10:15:51PM -0500, Roland McGrath wrote:
> > > Ok, I can try to find out where the references come from.
> >
> > Please do.
>
> ds_notify does a dev_port_lookup that acuires a reference. This reference
> i
On Mon, Oct 21, 2002 at 03:38:43AM -0700, Roland McGrath wrote:
> This driver handles only the lowest level of the PC keyboard & PS/2 mouse
> interface, and does almost the minimal work it can do. It is an oskit
> "bus" device like ide or scsi busses are, and has (at most) two slots,
> called "kbd
> Do you mean that in fact the system comprehensively locates every
> device the first time any device is opened?
In effect, yes.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> Ok, well then that works certainly. :) I wish there was a solution
> to the harder problem that's always bugged me though. (Dynamic
> probing of hardware at runtime.)
I'm sure there is. But it's not very interesting to me to think about the
details much until we are actually implementing som
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Do you mean that in fact the system comprehensively locates every
> > device the first time any device is opened?
>
> In effect, yes.
Ok, well then that works certainly. :) I wish there was a solution
to the harder problem that's always bugged me
On Fri, Nov 08, 2002 at 10:15:51PM -0500, Roland McGrath wrote:
> > Ok, I can try to find out where the references come from.
>
> Please do.
ds_notify does a dev_port_lookup that acuires a reference. This reference
is not released. So when the last user goes away, and the notification is
sent,
> I didn't update the io bitmap offset at all task switches. I only covered
> stack_handoff and not switch_context. I don't really understand what each
> is used for, but it's quite obvious that it is needed in both and testing
> verified the following change:
stack_handoff is for a context swit
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Hrm. Sure, that's fine for the main hard disk.
>
> You missed the point. The probe is recursive.
Hrm, maybe I'm being misled by the use of "probe". I usually take
"probe for X" to mean "hunt around for X until you find it". Is there
a differen
> Hrm. Sure, that's fine for the main hard disk.
You missed the point. The probe is recursive.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Fri, Nov 08, 2002 at 10:15:51PM -0500, Roland McGrath wrote:
> > Another serious bug is that my I/O permission stuff is not working properly.
> > There seems to be a race of some sort.
>
> In that case you really want to put a bkpt at i386_exception or suchlike
> and find exactly what is happen
Roland McGrath <[EMAIL PROTECTED]> writes:
> Anyway, this kind of question is for the device manager thingie to worry
> about in the long run. Conceptually, the kernel should not be thinking
> about peripheral hardware, and the device interfaces in oskit-mach are just
> a makeshift solution putti
> Ok, I can try to find out where the references come from.
Please do.
> Right now what I am doing is to read from kbd byte by byte. I will change
> it to read many bytes at once (as much as the internal buffer is), and then
> process the local buffer first, before reading more. However, readin
On Fri, Nov 08, 2002 at 06:26:09PM -0500, Roland McGrath wrote:
> > it won't be a problem in my console, as I am opening it once with read/write
> > permission. But of course it needs to be fixed. I don't know where the
> > three references come from. They are not increased by subsequent
> > ope
> it won't be a problem in my console, as I am opening it once with read/write
> permission. But of course it needs to be fixed. I don't know where the
> three references come from. They are not increased by subsequent
> open/close, so they might come from the code that creates and enters the
>
On Thu, Nov 07, 2002 at 01:43:28PM -0500, Roland McGrath wrote:
> > Writing of the bytes doesn't seem to work properly, I set up streamio
> > (cat'ing from that works fine), and then I tried
> >
> > echo $'\xED\x07' > kbd
>
> The examples/x86/i8042 test program does just that, and it works (light
> This is an interesting strategy. Long ago, I recall there being
> devices on a Vax that you couldn't reliably probe this way, because
> the bus could hang for several seconds during the probe for various
> reasons.
In practice, the probe always happens very early. The first time a
device_ope
Roland McGrath <[EMAIL PROTECTED]> writes:
> In oskit-mach, we only probe on demand in device lookup, so you'd have to
> insert an early oskit_bus_probe (osenv_rootbus_getbus ()); call to see
> anything from oskit_dump_devices.
This is an interesting strategy. Long ago, I recall there being
devi
> I thought the bus walk was to find a leaf in a hierarchy of devices, where
> the bus is a top node of the devices on the bus. Ie, like "i8042:kbd" etc.
> But that might be pure fiction, I never really groked the way devices are
> organized in oskit.
That is right, it's a tree where the non-lea
On Thu, Nov 07, 2002 at 01:43:28PM -0500, Roland McGrath wrote:
> > Confirmed. What is the non-bus-walk name of these devices (just curious)?
>
> What do you mean? Devices don't have flat names. The names like "eth0"
> and so forth are compatibility hacks in bus_walk_from_compat_string.
I thou
> Confirmed. What is the non-bus-walk name of these devices (just curious)?
What do you mean? Devices don't have flat names. The names like "eth0"
and so forth are compatibility hacks in bus_walk_from_compat_string.
> Ah, which reminds me that I still use device_read and not
> device_read_inba
> On Mon, Oct 21, 2002 at 03:38:43AM -0700, Roland McGrath wrote:
> > Included in the oskit patch is the examples/x86/i8042 test program, which
> > is the only thing I have used with the driver so far. Build that oskit
> > kernel
>
> Do you have a patch for examples/x86/GNUmakerules for that?
-
On Mon, Oct 21, 2002 at 03:38:43AM -0700, Roland McGrath wrote:
> Included in the oskit patch is the examples/x86/i8042 test program, which
> is the only thing I have used with the driver so far. Build that oskit
> kernel
Do you have a patch for examples/x86/GNUmakerules for that?
Thanks,
Marcus
25 matches
Mail list logo
