John,
On 15-01-19 10:34 PM, John Crispin wrote:
On 20/01/2015 01:21, Owen Kirby wrote:
Add hotplug support for tty devices in /etc/inittab that are specified
by the askfirst
keyword so that terminals attached after boot time get console processes
started.
This was tested on an AT91 target using the gadget serial subsystem and
on an WNDR3800
with a USB serial adapter. One possible weirdness I encountered was that
the baud rates
and control modes sometimes need adjusting with a hotplug script after
reconnecting
the adapter. This is also only implemented for askfirst, but it might
also make sense
to do the same thing for respawn and askconsole.
i think it would be a lot simpler if you ...
* add a new cmd_handler inside hotplug/json_script called console or
spawn_console
* add a 2nd parameter to procd_inittab_run called char *tty that can be
NULL or act as a filter
* call procd_inittab_run with the 2nd parameter set from the new
json_script handler
* add a new if clause to package/system/procd/files/hotplug.json
I'm not sure that would really be any simpler. The cmd_handler would
need to deal with respawning the console process and would wind up
duplicating a the code already in inittab.c. It seemed like less work to
simply extend the hotplug system to add a way for the inittab.c code to
receive notifications of hotplug events. There is also the question of
where this 2nd parameter to procd_inittab_run would come from, would we
need to parse the /etc/hotplug.json script for anything that might spawn
a console, and what if there were multiple consoles created this way in
the hotplug script?
Furthermore, it seems like the description of which tty devices should
spawn consoles and which devices don't is really a board-specific
configuration item that seems inappropriate to put into /etc/hotplug.json.
Although, adding a new cmd_handler for creating consoles is an
interesting idea. We could get rid of /etc/inittab entirely by creating
all the consoles that way.
But, if you really think that's the best approach then I'll code up a
3rd version of the patch for you.
Cheers,
Owen
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
