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
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The doc says that you are allowed to create auth objects associated with any
> IDs if you have euid 0, and the code actually allows it even if only auid 0.
>
> (Because isroot() uses isuid() and isuid() allows both).
>
> Is the code wrong or the doc
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
> The doc says that you are allowed to create auth objects associated with any
> IDs if you have euid 0, and the code actually allows it even if only auid 0.
>
> (Because isroot() uses isuid() and isuid() allows both).
I think it needs to be fixed. In POSIX.1, seteuid(123) should not work if
you
> 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
Hi,
The doc says that you are allowed to create auth objects associated with any
IDs if you have euid 0, and the code actually allows it even if only auid 0.
(Because isroot() uses isuid() and isuid() allows both).
Is the code wrong or the documentation? I think we should fix the code.
Thanks,
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
12 matches
Mail list logo
