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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux