[BRLTTY] Honor distribution LDFLAGS when building drivers
Dave Mielke
Dave at mielke.cc
Thu May 24 13:15:53 EDT 2018
[quoted lines by Jaroslav Skarvada on 2018/05/24 at 12:54 -0400]
>> Would it make sense to also add rescue.target?
>>
>OK, I think it could be helpful, I will add it.
Thanks. I'm now wondering if, maybe, there should be a new target (for now,
let's call it interactive.target). It could then have the WantedBy= for
multi-user, rescue, and emergency, and then services like brltty could be
WantedBy=interactive.target. That'd keep the information all in one place. Of
course, I guess, assuming that it's is a good idea, it'd need to be a systemd
change rather than a Fedora administrative change.
>During the next week I should have an intern handy for this task.
>He could prepare some proof of concept implementation.
That'd be really cool!
>But if you want to play with it I think inspiration can be taken
>from e.g. /usr/lib/dracut/modules.d/98syslog
>There is some documentation (unfortunately incomplete) in manual page
>dracut.modules.
I'll check them out.
>I am afraid there is nothing (or at least I don't know about) like good
>tutorial or document describing best practices.
That's often the case. It's just that, with boot stuff, I'm extra cautious
since, if something goes wrong, then I'm stuck until such time (which can take
a while) I can have competent sighted assistance.
>From what I know:
>It will require module-setup.sh, which should install runtime
>shared libraries (libbluetooth should be probably enough, because other
>libraries seems to be already present in the dracut image). Then it should
>copy /etc/brltty.conf to the image, parse it and include all enabled drivers
>and tables from the /etc/brltty and /usr/lib64/brltty. We could include
>everything, but I think it would waste space in the image. Probably
>better is to include only enabled things and maybe allow override through the
>environmental variables (used when the dracut image is generated). It will
>also require writing hooks (and installing them) for brltty service
>startup and cleanup. We may also parse kernel command line arguments
>for e.g. arguments prefixed by 'brltty.' to allow override for driver
>selection during boot (from drivers installed in the dracut image).
>Code snippets for all of this can be taken from the above mentioned syslog
>module
Excellent! The problem with parsing these files is that they use lots of
includes which can nest quite deeply. Also, they support variales, and the
included paths can contain them. If they really should be parsed then the
safest way might be to add an option to brltty which would dump the full file
set for a given file.
--
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke
Phone: +1 613 726 0014 | Canada K2A 1H7 |
More information about the BRLTTY
mailing list