Re: [RFC 4/4] firewire: add mem1394

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]