RE: Reliability of RPC services

[Christopher Nelson]

> 
> Scribit Christopher Nelson dies 26/04/2006 hora 09:43:
> > You specifically mention ATA and SCSI.
> 
> I did not.

I apologize, someone else must have written that in a message that you
replied to.
 
> > I suspect that you may mean something more like having the 
> ability to 
> > mount a custom filesystem on some given device, restrained 
> to a given 
> > range of device blocks.
> 
> I do not. I meant being able to send whatever I want to the 
> device itself. I don't know if it needs access to the bus 
> where the device is.
> I suspect it only needs to be able to tell to the bus driver 
> what to send to the specified device.

That depends on whether you want register-level access, or block level
access. If you want block-level access, then what you want is a custom
filesystem-like API.  That's all a filesystem is, really, an interface
to some block device.  Some devices have a packet interface, but IMHO,
that is simply to unrestricted to allow.  If you allow any client to
construct an ATA packet, for example, they can have unrestricted access
to any device on the bus.   Putting a packet filter in place might help
that, but it adds complexity that is pointless.

> e.g. if I can hotplug my own SCSI disk, I don't need to deal 
> myself with the SCSI bus. All I need is the bus sending 
> whatever I tell it to, but only to my device.
> 
> Maybe it's already to much, given the design of SCSI, IDE or 
> USB bus, I've no knowledge of that part.

I agree that there should be a way to give users open access to hotplug
devices like USB, etc, but on the other hand, what if your OS boots off
of a USB flash device?  There are certainly ways to do what you propose,
but they add a needless layer of complexity.  It would be better to use
a higher level of permission, perhaps like mount points, that would let
a user read and write data on hot plug devices that get plugged in
during their session.  But this completely open access to the bus and/or
device registers breaks security confinement in a fundamental way.


> BTW: your MUA is broken, adding some illegal headers about 
> threads but not the standards one, thus breaking threads, at 
> least in my MUA, which is not very comfortable in such 
> ramified discussions...

I use Outlook, sorry.

-={C}=-