Re: [RFC 2] userconf(4): 2nd proposal
One thing I'd like to point out is that I often find I don't have the right keyboard layout or am restricted in some way in from typing in the bootloader (glitchy serial connection or really fast repeating keyboard or something), so keeping the syntax brief and with as few non- alphabetical characters as possible would probably be a good idea. Just throwing some cents on the pile, Staffan
Re: [RFC 2] userconf(4): 2nd proposal
FWIW, various things I have modified can be seen here: https://github.com/tlaronde/netbsd-src/tree/tsjl The userconf version present at the moment on the published branch, was my first attempt (patterns introduced by slashes---working but not solving the problem about drmkms). There are other bits listed at the root in CHANGES.tsjl (other files: WIP.tsjl and GOALS.tsjl are self-explanatory, but GOALS is empty at the moment except for the title and the date and will have to be filled when the documentation is ready). Next step will be to implement patterns and groups for userconf/config(1), but with a revised syntax as proposed by RVP (but for now, I will go with groups defined by config(1), and not allowing variables aka aliases, first to not implement custom allocation, second to allow the feature to be of use for all archs, and not only the ones using boot.cfg). I may probably not report on the list when done for this or even about what I will be doing next: this will be explained in the files mentionned above and the sources will be published in the branch. If something is found useful by somebody, just cherry-pick (my work published here is under a 2 clauses BSD licence). -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sun, Nov 05, 2023 at 11:17:02AM +, RVP wrote: > > Oh, I like the idea (I've always wanted a mechanism to list drivers > etc. using patterns); it's just the syntax that sticks in the craw. > Too many meta-chars. there. > > OTOH, `cmd -p xyz* *abc' doesn't need much thought. And, aliases > are pretty standard too. But, this is your show, n'est pas...? > Don't let me stop you! I like this more: flags introduced by '-' since if a flag is not a number there is no ambiguity with negative numbers (allowed for the more builtin facility). So -p would mean pattern, -g use groups instead of driver name and -pg apply a pattern to group names and even -s meaning STARred (-pgs, letters in whatever order, meaning apply a pattern to group names for STARred devices)... And without flags, this is the present syntax untouched. This will address too the legitimate concern of Staffan Thomén about keyboard mapping: this adds less characters, and not special ones. For variables, I will refrain for the moment because this will impose to add a fraction of a page (1/4, 1/2 or 1/1) as scratch "memory" to allocate and a simple allocation scheme (a la Unix version 6 for example: see Lion's Commentary) in order to not allocate with kernel facilities. Not difficult, not adding much but if not necessary... -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sun, Nov 05, 2023 at 01:53:31PM +0200, Staffan Thomén wrote: > One thing I'd like to point out is that I often find I don't have the > right keyboard layout or am restricted in some way in from typing in the > bootloader (glitchy serial connection or really fast repeating keyboard > or something), so keeping the syntax brief and with as few non- > alphabetical characters as possible would probably be a good idea. > > Just throwing some cents on the pile, I have been annoyed by that too (a GENERIC kernel has a US qwerty default compiled in) and I wondered if a supplementary short command to switch the mapping, in userconf, would not be convenient too (no need to deal with accented characters or whatever: just providing the ASCII chars where the engraving of a different keyboard puts there). For the extra characters, I think what can be accessible on the numpad is handy (I even had * not accessible with some USB keyboards...). This leaves the braces (for the groups) more problematic. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, 4 Nov 2023, tlaro...@kergis.com wrote: You can also add, let's say, a `-g' group flag: uc> list -g # list all "groups" uc> list -g drmkms # list devices in group drmkms uc> disable -g drmkms# disable group drmkms Yep, but know you see what became of the simplifications ;-) :) Only because I bent over backwards to accomodate "groups" (which you can skip if have aliases). I covered the same ground as you to end up with my first proposal, in order, by the '=' to allow the keep the present syntax alone and to have a new differing, and imposing double quoting of strings in order to be able, if needed, later, to have variable names unquoted, precisely for use in boot.cfg. I think that my second proposal is the simplest, allowing not breaking existing and introducing extensions without much typing. Oh, I like the idea (I've always wanted a mechanism to list drivers etc. using patterns); it's just the syntax that sticks in the craw. Too many meta-chars. there. OTOH, `cmd -p xyz* *abc' doesn't need much thought. And, aliases are pretty standard too. But, this is your show, n'est pas...? Don't let me stop you! -RVP
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, Nov 04, 2023 at 11:59:00AM +0100, Martin Husemann wrote: > On Sat, Nov 04, 2023 at 11:25:01AM +0100, tlaro...@kergis.com wrote: > > I think that my second proposal is the simplest, allowing not breaking > > existing and introducing extensions without much typing. > > This whole thing still makes no sense to me. You can do what you want > with userconf already and this is not a common operation so any simplification > for something that only makes sense (1) for ad hoc testing or (2) encoded > in boot.cfg does not gain us anything for real. > > For the real world issue at hand (bugs in kernel drivers that claim the > console but then do not work) either a boot flag (like RB_MD4 on x86) > or what you call "ad hoc mechanism" makes a lot more sense to me. An "ad hoc mechanism" would be to construct a list of drivers to disable them in block i.e. exactly the same as what can be done already with userconf if you know the drivers names. The only advantage of this ad hoc solution would be to require only a generic instruction instead of several commands to disable all or the necessity to know exactly which one to disable. This is what my proposal is about, but instead of polluting the sources with an "ad hoc" solution, by adding a feature that can be of some more general use in other cases, for debugging or disabling a collection of devices (group). So how can you discard my proposal as "no sense", when your ad hoc solution is only a variation around the same thing? Secondly, a more fine grained solution to disable a portion of the drivers dealing with the console is more involved---because if it was not, it would have already been done, no? And this is the problem: the drm2/ source is 206 MB (!!!). Our drmkms sources are already not in sync with the Linux ones (I'm watching them and there have been already major changes, for i915 and particularily for amdgpu). So the NetBSD turtle may beat the Linux hare, but in the end; certainly not in a speed race... And there is the NetBSD 10 release. A definitive or even only correct solution will not be found if 10 has to be released soon. I'm just proposing something simple enough to improve the "crude solution"---on par with the Linux/GRUB feature. That's the best that can be done for the time being due to the size (that's the word...) of the problem... -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, Nov 04, 2023 at 11:25:01AM +0100, tlaro...@kergis.com wrote: > I think that my second proposal is the simplest, allowing not breaking > existing and introducing extensions without much typing. This whole thing still makes no sense to me. You can do what you want with userconf already and this is not a common operation so any simplification for something that only makes sense (1) for ad hoc testing or (2) encoded in boot.cfg does not gain us anything for real. For the real world issue at hand (bugs in kernel drivers that claim the console but then do not work) either a boot flag (like RB_MD4 on x86) or what you call "ad hoc mechanism" makes a lot more sense to me. Of course the bugs in the drivers should be fixed, so this is only a temporary workaround. Martin
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, Nov 04, 2023 at 09:30:53AM +, RVP wrote: > On Sat, 4 Nov 2023, tlaro...@kergis.com wrote: > > > > > No...: this is a break of existing. Trailing `*' selects STARred devices > > > > (I'm not the inventor of this). So `*' can not be used as a joker ;-) > > > > > > > > > > You can allow escapes for those: > > > > > > uc> disable i915drmkms\* # exact match STARred > > > uc> disable *kms\*# only STARed `*kms' > > > > > > > But this breaks existing... > > > > Fine. You can introduce the notion of flags. > For example `-p' for pattern: > > uc> disable i915drmkms* # std. starred device > uc> disable -p *drm* # disable using pattern > > You can also add, let's say, a `-g' group flag: > > uc> list -g # list all "groups" > uc> list -g drmkms# list devices in group drmkms > uc> disable -g drmkms # disable group drmkms > Yep, but know you see what became of the simplifications ;-) I covered the same ground as you to end up with my first proposal, in order, by the '=' to allow the keep the present syntax alone and to have a new differing, and imposing double quoting of strings in order to be able, if needed, later, to have variable names unquoted, precisely for use in boot.cfg. I think that my second proposal is the simplest, allowing not breaking existing and introducing extensions without much typing. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, 4 Nov 2023, tlaro...@kergis.com wrote: No...: this is a break of existing. Trailing `*' selects STARred devices (I'm not the inventor of this). So `*' can not be used as a joker ;-) You can allow escapes for those: uc> disable i915drmkms\* # exact match STARred uc> disable *kms\* # only STARed `*kms' But this breaks existing... Fine. You can introduce the notion of flags. For example `-p' for pattern: uc> disable i915drmkms* # std. starred device uc> disable -p *drm* # disable using pattern You can also add, let's say, a `-g' group flag: uc> list -g # list all "groups" uc> list -g drmkms # list devices in group drmkms uc> disable -g drmkms# disable group drmkms -RVP
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, Nov 04, 2023 at 08:31:09AM +, RVP wrote: > On Sat, 4 Nov 2023, tlaro...@kergis.com wrote: > > > > 1) Allowing shell-like patterns (not hard to implement): > > > > > > uc> disable drm* # all starting with `drm' > > > > No...: this is a break of existing. Trailing `*' selects STARred devices > > (I'm not the inventor of this). So `*' can not be used as a joker ;-) > > > > You can allow escapes for those: > > uc> disable i915drmkms\* # exact match STARred > uc> disable *kms\*# only STARed `*kms' > But this breaks existing... > > I have contemplated, too, adding for example "variables" to userconf and > > rejected it because this would be only useful for arch supporting > > boot.cfg, > > > > Definition in boot.cfg was the intent. Yes, this could be useful but for boot.cfg; but boot.cfg is not supported by all archs. Hence the "grouping" proposal, that is independent from boot.cfg, and that can have, IMO, a usage not limited to drmkms---a group being defined so that the devices enabled/disabled by group can, indeed, work or not imped the behavior of the kernel if disabled; I made experiments disabling devices with pattern matching for drmkms, ending disabling a child with the simple result that I painted myself in a corner: there was no more display... So grouping is also supposed to be "safe" variables definition. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, Nov 04, 2023 at 08:20:43AM +, Michael van Elst wrote:
> tlaro...@kergis.com writes:
>
> >disable {drmkms} # NEW: disable devices belonging to group "drmkms"
>
> Almost noone would need to turn off all drmkms drivers. What you may
> want to control is that a GPU isn't used as a console. Disabling a driver
> is just our crude workaround to achieve this.
The problem is, at the moment, that we can not separate the GPU
handling from the drmkms stuff, meaning that one can not modify "at
run time" because, in some cases, one never gets to "run time": it
crashes.
The drmkms code (drm2/) has increased the size of the kernel sources
by... 50% (!). A "correct" solution can not be found now by diving in
the drmkms code.
So the crude workaround has to be achieved in a simpler way than
listing all the drmkms related drivers: a user trying GENERIC
does not necessarily know what is present on his hardware and does not
have to find what particular drivers he has to disable/enable.
>
> I don't think that autoconf is the right place for such a control,
> it should be a boot parameter, maybe even something that can be
> changed at runtime later.
>
> The current system of boot parameters is limited and differs a lot
> between platforms. We need a common way to set boot parameters and
> these should be mostly defined in a platform-agnostic way.
>
For the moment, putting definition of groups in config(1) and handling
in userconf, achieves this goal of arch independence.
And since the problems with drmkms are mainly for x86 machines, there
is for x86 boot.cfg in which by default we could disable drmkms and
simply instruct user to enable it (try once) at userconf console with
"enable {drmkms}" and, if this works, to comment out the
"disable {drmkms}" in boot.cfg.
>
> >Hint: Linuces distributions "work" as proposed images on servers,
> >where NetBSD fails.
>
> Servers usually do no have drmkms capable hardware, and if they have,
> you probably want to use that hardware.
Been there and seen this (I mean: didn't see anything...): to use the
hardware, you have to know it is here; when drmkms makes the kernel
crash, on a remote node without remote boot administration/console,
you will never know what it has and you will think that NetBSD
simply doesn't work...
So, disabling drmkms to verify that NetBSD works without it allows
you to know what the hardware is and, after that, you can try
to enable drmkms at least knowing that if it crashes (if you don't have
access anymore...), this does not mean that NetBSD can not drive it,
simply that this has to be without drmkms (we need to have a boot once
feature too so that if a remote node crashes, rebooting restore a
working boot sequence).
--
Thierry Laronde
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, 4 Nov 2023, tlaro...@kergis.com wrote: 1) Allowing shell-like patterns (not hard to implement): uc> disable drm* # all starting with `drm' No...: this is a break of existing. Trailing `*' selects STARred devices (I'm not the inventor of this). So `*' can not be used as a joker ;-) You can allow escapes for those: uc> disable i915drmkms\* # exact match STARred uc> disable *kms\* # only STARed `*kms' I have contemplated, too, adding for example "variables" to userconf and rejected it because this would be only useful for arch supporting boot.cfg, Definition in boot.cfg was the intent. -RVP
Re: [RFC 2] userconf(4): 2nd proposal
tlaro...@kergis.com writes:
>disable {drmkms} # NEW: disable devices belonging to group "drmkms"
Almost noone would need to turn off all drmkms drivers. What you may
want to control is that a GPU isn't used as a console. Disabling a driver
is just our crude workaround to achieve this.
I don't think that autoconf is the right place for such a control,
it should be a boot parameter, maybe even something that can be
changed at runtime later.
The current system of boot parameters is limited and differs a lot
between platforms. We need a common way to set boot parameters and
these should be mostly defined in a platform-agnostic way.
>Hint: Linuces distributions "work" as proposed images on servers,
>where NetBSD fails.
Servers usually do no have drmkms capable hardware, and if they have,
you probably want to use that hardware.
Re: [RFC 2] userconf(4): 2nd proposal
r...@sdf.org (RVP) writes: >On Sat, 4 Nov 2023, RVP wrote: >> 1) Allowing shell-like patterns (not hard to implement): >> >> uc> disable *drm* *usb$ # all with `drm' anywhere and those ending in >> >Ah, since these are shell-like patterns there's not need for a `$' to >denote EOL. So: userconf already supports "patterns", just not in the way you think.
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, Nov 04, 2023 at 07:41:19AM +, RVP wrote:
> On Sat, 4 Nov 2023, tlaro...@kergis.com wrote:
>
> > - 1) No change to the general form of current syntax;
> >
> > - 2) Selection can be as presently: by number (index in cfdata), by
> > name (driver name), but also (NEW) by pattern: a pattern is
> > between slashes, it is a fix substring, that can be optionnally
> > anchored at the beginning with `^' and at the end with `$';
> >
> > - 3) (NEW) If the selector (will this word do?) in 2) is surrounded by
> > braces `{' `}', the selector is for a group of devices;
> >
> > - 4) The STAR (existing) is still handled as a suffix.
> >
> > Examples:
> >
> > disable i915drmkms # existing syntax
> >
> > disable {drmkms}# NEW: disable devices belonging to group "drmkms"
> >
> > disable {/^drm/}* # NEW: disable devices belonging to groups
> > # whose name begins with the substr "drm" if
> > # they are STARred ones.
> >
>
> I think you can simplify things a bit by:
>
> 1) Allowing shell-like patterns (not hard to implement):
>
> uc> disable drm* # all starting with `drm'
No...: this is a break of existing. Trailing `*' selects STARred devices
(I'm not the inventor of this). So `*' can not be used as a joker ;-)
> uc> disable *drm* *usb$ # all with `drm' anywhere and those ending in
> `usb'
> uc> disable foo # exact match `foo'
> uc> disable 1 # exact match 1 (index)
>
> 2) Having an alias facility:
>
> uc> alias drm_disable=disable i915*; disable *radeon*; ...
> uc> drm_disable # executes: RHS text (no recursive expansion)
> uc> alias drm_disable=# remove alias `drm_disable'
I have contemplated, too, adding for example "variables" to userconf and
rejected it because this would be only useful for arch supporting
boot.cfg, and useless in userconf per se.
It is useless in userconf per se, because it is not persistent: the
time one will spend defining the aliases would be longer than the time
to type directly the disabling of several devices at userconf prompt ;-)
The goal, for me, is to have something generic, available on all
archs (hence put it in kern/subr_userconf.c and config(1)), and not an
ad hoc trick for drmkms, so that there is not something we have to
remember to update when something changes (groups will be set for the
benefits of userconf by config(1) with a macro added for the purpose).
--
Thierry Laronde
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, 4 Nov 2023, RVP wrote: 1) Allowing shell-like patterns (not hard to implement): uc> disable *drm* *usb$ # all with `drm' anywhere and those ending in Ah, since these are shell-like patterns there's not need for a `$' to denote EOL. So: uc> disable *drm* *usb # all with `drm' anywhere, and those ending in `usb' -RVP
Re: [RFC 2] userconf(4): 2nd proposal
On Sat, 4 Nov 2023, tlaro...@kergis.com wrote:
- 1) No change to the general form of current syntax;
- 2) Selection can be as presently: by number (index in cfdata), by
name (driver name), but also (NEW) by pattern: a pattern is
between slashes, it is a fix substring, that can be optionnally
anchored at the beginning with `^' and at the end with `$';
- 3) (NEW) If the selector (will this word do?) in 2) is surrounded by
braces `{' `}', the selector is for a group of devices;
- 4) The STAR (existing) is still handled as a suffix.
Examples:
disable i915drmkms # existing syntax
disable {drmkms}# NEW: disable devices belonging to group "drmkms"
disable {/^drm/}* # NEW: disable devices belonging to groups
# whose name begins with the substr "drm" if
# they are STARred ones.
I think you can simplify things a bit by:
1) Allowing shell-like patterns (not hard to implement):
uc> disable drm* # all starting with `drm'
uc> disable *drm* *usb$ # all with `drm' anywhere and those ending in `usb'
uc> disable foo # exact match `foo'
uc> disable 1# exact match 1 (index)
2) Having an alias facility:
uc> alias drm_disable=disable i915*; disable *radeon*; ...
uc> drm_disable # executes: RHS text (no recursive expansion)
uc> alias drm_disable= # remove alias `drm_disable'
-RVP
