Hi Jakub,
Jakub wrote:
">
> I guess for "real" serial ports (that have sockets on the chassis) we
> want a configuration utility that allows you to select what's connected
> (since reliable auto detection is probably not possible).
For that we already use the boot argument."
Sure, but as you said yourself that's pretty basic. Ideally you want the
system to store persistent configuration for each known serial port and
allow you to configure what's connected via cli/tui/gui/whatever (e.g.
serial terminal, mouse, SLIP, PPP, ...). That implies you need to be able to
persistently identify those devices (physical path works for onboard
devices, for USB devices you probably want to use the serial number). Of
course being able to override that via a boot argument is useful.
The components in such architecture would be:
- persistent device identification mechanism (probably a separate service
that would decorate device tree nodes with identity properties based on some
rules, udev could be the Linux equivalent)
- a configuration repository (device identity -> configuration)
- when adding a device the particular driver would look up the
configuration repository to decide what it should attach under the device
function (i.e. whether to set as inner or exposed, what match ID or category
to add)
- a configuration utility to edit the configuration repository
"There is a way to figure this out from the OFW tree. But then there is a
problem to figure out the correspondence between the OFW tree nodes and
the DDF device nodes. And then there is a question of who should attempt
to find the correspondence. Certainly not the uart driver. Maybe the
platform driver? After its entire subtree is built? Or should the
platform driver simply use some kind of regex to rewrite the OFW path
into our location service path? Even before its subtree is fully
initialized?"
That depends on what kind of driver/device-specific information is needed to
do this. Could be implemented by the DDF/drivers themselves or by a
completely separate service. The information gathered could be used to set
up reasonable default (or fixed) configuration in the configuration repo.
Cheers,
Jiri
"
Jakub
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
"
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
