[lkml]   [2006]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 4/4] firewire: add mem1394
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.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2006-02-07 14:57    [W:0.090 / U:0.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site