On Sun, 2006-02-05 at 15:19 +0100, Stefan Richter wrote: > > + * But I need advice on this. It'll probably works this way > > + * but most likely not once this interface stuff gets more > > + * use; I can imagine using it for scanners instead of raw1394 > > + * so that the kernel can validate that a user can only > > + * access a certain scanner and not all 1394 devices on the bus. > > Probably not. All devices (except perhaps custom embedded devices) which > implement one or another high level protocol will always be accessed > either by a protocol driver in kernelspace (like sbp2, eth1394, > video1394) on top of a struct unit_directory, or by a driver or library > in userspace on top of libraw1394/ raw1394. This is because such devices > and protocols all implement the ISO/IEC 13213 CSR architecture. You snipped too much :) At this point I was thinking of the raw1394 replacement that has finer grained access control which we talked about in other threads too. > > + * In other words some 'raw1394intf' instead of 'raw1394' which > > + * creates one character device per ieee1394 node for finer > > + * grained access control. > > + * That would definitely want to have debouncing etc. > When a node represented by a node_entry leaves the bus, the node_entry > is "suspended" and "put into limbo", which is both the same for the 1394 > stack. The node_entry is only "removed" when forced by userspace through > ieee1394's sysfs interface or when the ieee1394 driver module is > unloaded. A unit_directory is either "suspended" or "removed", depending > on what the protocol driver bound to the unit_directory implements. > This behaviour of ieee1394 is currently not extensively used, but I plan > to implement capability of sbp2 to survive transient disconnection on > top of it. Thanks for the explanation. I'll have to test my driver under the light of this. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- [RFC 0/4] firewire: interface to remote memory (mem1394)
- From: Johannes Berg <[email protected]>
- [RFC 4/4] firewire: add mem1394
- From: Johannes Berg <[email protected]>
- Re: [RFC 4/4] firewire: add mem1394
- From: Stefan Richter <[email protected]>
- [RFC 0/4] firewire: interface to remote memory (mem1394)
- Prev by Date: Re: [RFC 3/4] firewire: unconditionally export hpsb_send_packet_and_wait
- Next by Date: Re: Development of Ricoh Memory Host Adapter
- Previous by thread: Re: [RFC 4/4] firewire: add mem1394
- Next by thread: Measure the Accept Queueing Time
- Index(es):
 |