Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 8 years ago

Closed 8 years ago

#296 closed enhancement (fixed)

DDF should support pseudo-devices

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
Component: helenos/unspecified Version:
Keywords: Cc: vojtech.horky@…
Blocker for: Depends on:
See also:

Description

Currently any devman-based device must come into existence by being enumerated by some nexus (bus) device. This is inconvenient for pseudo-devices such as {{file_bd}}.

The distinction here is that for these pseudo-devices, it would be better if the device lifecycle was not controlled by DDF, but rather by the pseudo-device driver itself.

Change History (4)

comment:1 Changed 8 years ago by Jiri Svoboda

I propose for a pseudo-driver to have the following properties:

  • It does not live under the drv directory, it is not started by devman. Pseudo-driver lifecycle is out of scope of the DDF
  • It is any server which chooses to connect to devman and register as a driver
  • It can create one or more pseudo-devices
  • The bottom half of the pseudo-devices is out of scope of the DDF, while the top half (functions) is in scope

I plan looking into this when I am done with ticket #295

comment:2 Changed 8 years ago by Vojtech Horky

Cc: vojtech.horky@… added

comment:3 Changed 8 years ago by Jakub Jermář

Type: defectenhancement

comment:4 Changed 8 years ago by Jiri Svoboda

Resolution: fixed
Status: newclosed

I consider this ticket as solved since introduction of the Location service in mainline,1144. Thanks to that (and also since drivers can now handle client connections by themselves), DDF drivers and other servers are indistinguishable for a client.

Thus a pseudo-driver now corresponds to a regular server. The only exception would be a pseudo-nexus driver (such as USB host controller connected over a network). Since we currently don't intend to implement such drivers, we can leave this case for now.

Note: See TracTickets for help on using tickets.