Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 05:36:20PM -0700, Theo de Raadt wrote: > >> If there are desires to improve this (I hear Naddy grumbling!) then the > >> stomach to break backwards compat must be present, or suggestions on how > >> to do it without breaking backwards compat must be suggested. > > > >My suggestion is two-fold: > > > >* Introduce a new format. This new format will ignore # comments, > > call ! commands, but otherwise pass on everything unchanged to > > ifconfig. I'm neutral on the matter of retaining "dhcp" and > > "rtsol" as shortcuts for "!dhclient \$if" and "!rtsol \$if". > > > >* To maintain backward compatibility, retain the old parsing for > > hostname.* files. Interface configuration files in the new format > > will have a different name; if.* or whatever. > > > >Does that sound workable? > > Not really. The netbsd experiment with ifconfig file format does > not appear to have been a success. > > reason why? ifconfig has a really crummy argument parser, with all > sorts of side effects. hostname.* files were supposed to isolate > people from some of those nasty effects. > > stated simply, it would not have helped Paul. He would have made > the same mistake. > Plus some interface changes need multiple ifconfig commands and a specific order to work. I think there is no way to express complex interface configurations without having an order in which the operations are done. Sure it is possible to throw the ordering all into netstart but I think that is not helpful. -- :wq Claudio
sqlite3 3.7.14.1
Hi, here's a 250k diff to update our base sqlite3 to the latest 3.7.14.1 : http://rhaalovely.net/~landry/shared/sqlite-3.7.14.1.diff I hope i got the diff right, iirc no local modifications were made to the actual code. Mozilla 18 branch depends on it (for no good reason as usual) so i'd like to get it in in the coming weeks. Bumped major to 21.0, builds fine on amd64. No more testing than that.. i'll do a bulk build with it. Can we run the regress tests from databases/sqlite3 on the base sqlite ? Nothing fancy in the 3.7.14 and .1 releases : http://www.sqlite.org/changes.html Landry
Re: new device ids
Le 23/11/2012 08:35, Kirill Bychkov a écrit : > Hi. > This patch adds fingerprint reader and ati video, found on my girlfriend's hp > pavillion dv6. > OK? > > Index: pci/pcidevs > === > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.1661 > diff -u -r1.1661 pcidevs > --- pci/pcidevs 17 Nov 2012 15:42:29 - 1.1661 > +++ pci/pcidevs 23 Nov 2012 04:24:46 - > @@ -1264,6 +1264,7 @@ > product ATI RADEON_HD66700x6758 Radeon HD 6670 > product ATI RADEON_HD58000x6899 Radeon HD 5800 > product ATI RADEON_HD57000x68b8 Radeon HD 5700 > +product ATI MOBILITY_HD6550 0x68c1 Radeon Mobility HD 6550 > product ATI RADEON_HD56700x68d8 Radeon HD 5670 > product ATI MOBILITY_HD5470 0x68e0 Radeon Mobility HD 5470 > product ATI MOBILITY_HD5430 0x68e1 Radeon Mobility HD 5430 > Index: usb/usbdevs > === > RCS file: /cvs/src/sys/dev/usb/usbdevs,v > retrieving revision 1.592 > diff -u -r1.592 usbdevs > --- usb/usbdevs 21 Nov 2012 05:24:19 - 1.592 > +++ usb/usbdevs 23 Nov 2012 04:24:46 - > @@ -509,6 +509,7 @@ > vendor MOBILITY 0x1342 Mobility > vendor DICKSMITH 0x1371 Dick Smith Electronics > vendor NETGEAR3 0x1385 Netgear > +vendor VALIDITYSENSORS 0x138a Validity Sensors Inc. > vendor BALTECH 0x13ad Baltech > vendor CISCOLINKSYS 0x13b1 Cisco-Linksys > vendor SHARK 0x13d2 Shark > @@ -4052,6 +4053,9 @@ > > /* USI products */ > product USI MC60 0x10c5 MC60 Serial > + > +/* Validity Sensors Inc. products */ > +product VALIDITYSENSORS VFS301 0x0005 Fingerprint reader VFS301 > > /* Velleman products */ > product VELLEMAN K8055 0x5500 K8055 USB Experiment interface > board > > Looks good: http://www.pcidatabase.com/vendor_details.php?id=240 http://www.pcidatabase.com/vendor_details.php?id=1689
Re: hostname.if(5) clarification
>> If there are desires to improve this (I hear Naddy grumbling!) then the >> stomach to break backwards compat must be present, or suggestions on how >> to do it without breaking backwards compat must be suggested. > >My suggestion is two-fold: > >* Introduce a new format. This new format will ignore # comments, > call ! commands, but otherwise pass on everything unchanged to > ifconfig. I'm neutral on the matter of retaining "dhcp" and > "rtsol" as shortcuts for "!dhclient \$if" and "!rtsol \$if". > >* To maintain backward compatibility, retain the old parsing for > hostname.* files. Interface configuration files in the new format > will have a different name; if.* or whatever. > >Does that sound workable? Not really. The netbsd experiment with ifconfig file format does not appear to have been a success. reason why? ifconfig has a really crummy argument parser, with all sorts of side effects. hostname.* files were supposed to isolate people from some of those nasty effects. stated simply, it would not have helped Paul. He would have made the same mistake.
Re: hostname.if(5) clarification
Mark Kettenis: > I don't really see what this buys us. You still have to maintain the > backwards compat code. You'll end up with an inconsistent mess of > hostname.if and if.whatever files. And all of this to fix what exactly? To preserve my sanity every time I need to figure out how to bring ifconfig commands into a format that passes through the transformations done by the hostname.if parser. Remember how we were struggling with -autoconfprivacy a few months ago? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: hostname.if(5) clarification
On 2012/11/26 17:40, Jason McIntyre wrote: > anyway...i still dislike the idea of just saying order matters. also, > could someone really expect the file to not be parsed top down Yes, I think they might; people are used to config files being read and parsed before being applied, and because this file isn't a straight set of commands to pass to ifconfig(8) I think it's not unreasonable that someone should treat it as a config file.
Re: hostname.if(5) clarification
> From: na...@mips.inka.de (Christian Weisgerber) > Date: Mon, 26 Nov 2012 20:44:45 + (UTC) > > Todd T. Fries wrote: > > > If there are desires to improve this (I hear Naddy grumbling!) then the > > stomach to break backwards compat must be present, or suggestions on how > > to do it without breaking backwards compat must be suggested. > > My suggestion is two-fold: > > * Introduce a new format. This new format will ignore # comments, > call ! commands, but otherwise pass on everything unchanged to > ifconfig. I'm neutral on the matter of retaining "dhcp" and > "rtsol" as shortcuts for "!dhclient \$if" and "!rtsol \$if". > > * To maintain backward compatibility, retain the old parsing for > hostname.* files. Interface configuration files in the new format > will have a different name; if.* or whatever. > > Does that sound workable? I don't really see what this buys us. You still have to maintain the backwards compat code. You'll end up with an inconsistent mess of hostname.if and if.whatever files. And all of this to fix what exactly?
Re: hostname.if(5) clarification
Todd T. Fries wrote: > If there are desires to improve this (I hear Naddy grumbling!) then the > stomach to break backwards compat must be present, or suggestions on how > to do it without breaking backwards compat must be suggested. My suggestion is two-fold: * Introduce a new format. This new format will ignore # comments, call ! commands, but otherwise pass on everything unchanged to ifconfig. I'm neutral on the matter of retaining "dhcp" and "rtsol" as shortcuts for "!dhclient \$if" and "!rtsol \$if". * To maintain backward compatibility, retain the old parsing for hostname.* files. Interface configuration files in the new format will have a different name; if.* or whatever. Does that sound workable? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: hostname.if(5) clarification
Jason McIntyre wrote: >On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: >> On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: >> > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: >> > > Be more specific about the order of interpretation. Okay? >> > > >> > > diff --git share/man/man5/hostname.if.5 >share/man/man5/hostname.if.5 >> > > index b07459f..aa8446f 100644 >> > > --- share/man/man5/hostname.if.5 >> > > +++ share/man/man5/hostname.if.5 >> > > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. >> > > The configuration information is expressed in a line-by-line >packed format >> > > which makes the most common cases simpler; those dense formats >are described >> > > below. >> > > +The order of the configuration lines matters, they are >interpreted from the >> > > +top down. >> > > Any lines not matching these packed formats are passed directly >to >> > > .Xr ifconfig 8 . >> > > The packed formats are converted using a somewhat inflexible >parser and >> > > >> > >> > if we say this, then we should provide guidance to folks about how >to >> > order the lines. what is the specific problem, or the general rule, >that >> > you are addressing? >> >> Problem: >> >> /etc/hostname.iwn0: >> dhcp >> nwid foo >> wpakey bar >> >> Gets neighbour's lease then drops it then gets the lease from the foo >> network using the bar wpakey. >> >> Solution: >> >> /etc/hostname.iwn0 >> nwid foo >> wpakey bar >> dhcp >> >> Sets the network to foo and associates a password to it and then >tries >> to get a lease. >> >> Order matters. Perhaps there's a better way to phrase it but, as far >as >> guidance goes, I guess it's not quite possible to do that because >> ifconfig alone has a plethora of possible usages. >> > >does "dhcp nwid foo wpakey bar" give you problems too? because >hostname.if(5) suggests it should not: > > A DHCP-configured network interface setup consists of > > dhcp options > >so if it isn;t working, isn;t that indicative of a worse problem? or >that we have not documented how "dhcp" works sufficiently? > >we can;t just say order matters, but not provide any guidance. having >said that, i think the text "The packed formats are converted", which i >think deraadt added, was meant to address something like this. maybe he >remembers? > >anyway...i still dislike the idea of just saying order matters. also, >could someone really expect the file to not be parsed top down (i don;t >know, i'm just asking. it seems unlikely to me you'd start parsing from >the end and work up)? This was my first thought, too. With Ken's example it makes more sense.
Re: raw_usrreq - spl diff
On Mon, Nov 26, 2012 at 8:54 PM, Mark Kettenis wrote: >> Date: Mon, 26 Nov 2012 20:37:22 +0100 >> From: Mike Belopuhov >> >> We've discussed this with claudio and while there are might >> be some other related issues with pr_usrreq and spls, I think >> this particular diff needs to be committed. OK? > > Whenever a diff like this is proposed, it's worth considering to > sprinkle in some splassert's. > where do you want to put splasserts? i honestly don't see a place where it would matter: raw_usrreq will call splsoftnet itself. pfkey_* functions don't neet splnet for anything else.
Re: raw_usrreq - spl diff
> Date: Mon, 26 Nov 2012 20:37:22 +0100
> From: Mike Belopuhov
>
> We've discussed this with claudio and while there are might
> be some other related issues with pr_usrreq and spls, I think
> this particular diff needs to be committed. OK?
Whenever a diff like this is proposed, it's worth considering to
sprinkle in some splassert's.
> On Tue, Nov 13, 2012 at 14:18 -0500, David Hill wrote:
> > Hello -
> >
> > I originally asked mikeb if splnet was needed in net/pfkey.c. He added
> > onto my diff (which I have included below). I noticed route_usrreq from
> > net/rtsock.c calls raw_usrreq protected by splsoftnet.
> >
> > I thought I'd send it to tech@ to possibly get more feedback.
> >
> > Here is the diff I am running with. I haven't had any regressions.
> >
> > Index: sys/net/pfkey.c
> > ===
> > RCS file: /cvs/src/sys/net/pfkey.c,v
> > retrieving revision 1.19
> > diff -N -u -p sys/net/pfkey.c
> > --- sys/net/pfkey.c 20 Sep 2012 10:25:03 - 1.19
> > +++ sys/net/pfkey.c 11 Nov 2012 01:18:42 -
> > @@ -198,15 +198,12 @@ static int
> > pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p)
> > {
> > int rval;
> > - int s;
> >
> > if (!(socket->so_pcb = malloc(sizeof(struct rawcb),
> > M_PCB, M_DONTWAIT | M_ZERO)))
> > return (ENOMEM);
> >
> > - s = splnet();
> > rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p);
> > - splx(s);
> > if (rval)
> > goto ret;
> >
> > @@ -228,12 +225,10 @@ ret:
> > static int
> > pfkey_detach(struct socket *socket, struct proc *p)
> > {
> > - int rval, i, s;
> > + int rval, i;
> >
> > rval = pfkey_versions[socket->so_proto->pr_protocol]->release(socket);
> > - s = splnet();
> > i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p);
> > - splx(s);
> >
> > if (!rval)
> > rval = i;
> > @@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
> > struct mbuf *nam, struct mbuf *control, struct proc *p)
> > {
> > int rval;
> > - int s;
> >
> > if ((socket->so_proto->pr_protocol > PFKEY_PROTOCOL_MAX) ||
> > (socket->so_proto->pr_protocol < 0) ||
> > @@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
> > return (pfkey_detach(socket, p));
> >
> > default:
> > - s = splnet();
> > rval = raw_usrreq(socket, req, mbuf, nam, control, p);
> > - splx(s);
> > }
> >
> > return (rval);
> > Index: sys/net/raw_usrreq.c
> > ===
> > RCS file: /cvs/src/sys/net/raw_usrreq.c,v
> > retrieving revision 1.14
> > diff -N -u -p sys/net/raw_usrreq.c
> > --- sys/net/raw_usrreq.c11 Jan 2012 23:47:06 - 1.14
> > +++ sys/net/raw_usrreq.c11 Nov 2012 01:18:42 -
> > @@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> > {
> > struct rawcb *rp = sotorawcb(so);
> > int error = 0;
> > - int len;
> > + int len, s;
> >
> > if (req == PRU_CONTROL)
> > return (EOPNOTSUPP);
> > @@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> > error = EINVAL;
> > goto release;
> > }
> > + s = splsoftnet();
> > switch (req) {
> >
> > /*
> > @@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> > /*
> > * stat: don't bother with a blocksize.
> > */
> > + splx(s);
> > return (0);
> >
> > /*
> > @@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> > */
> > case PRU_RCVOOB:
> > case PRU_RCVD:
> > + splx(s);
> > return (EOPNOTSUPP);
> >
> > case PRU_LISTEN:
> > @@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> > panic("raw_usrreq");
> > }
> > release:
> > + splx(s);
> > if (m != NULL)
> > m_freem(m);
> > return (error);
Re: hostname.if(5) clarification
Penned by Kenneth R. Westerback on 20121126 12:58.45, we have: | On Mon, Nov 26, 2012 at 05:40:06PM +, Jason McIntyre wrote: | > On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: | > > On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: | > > > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: | > > > > Be more specific about the order of interpretation. Okay? | > > > > | > > > > diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 | > > > > index b07459f..aa8446f 100644 | > > > > --- share/man/man5/hostname.if.5 | > > > > +++ share/man/man5/hostname.if.5 | > > > > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. | > > > > The configuration information is expressed in a line-by-line packed format | > > > > which makes the most common cases simpler; those dense formats are described | > > > > below. | > > > > +The order of the configuration lines matters, they are interpreted from the | > > > > +top down. | > > > > Any lines not matching these packed formats are passed directly to | > > > > .Xr ifconfig 8 . | > > > > The packed formats are converted using a somewhat inflexible parser and | > > > > | > > > | > > > if we say this, then we should provide guidance to folks about how to | > > > order the lines. what is the specific problem, or the general rule, that | > > > you are addressing? | > > | > > Problem: | > > | > > /etc/hostname.iwn0: | > > dhcp | > > nwid foo | > > wpakey bar | > > | > > Gets neighbour's lease then drops it then gets the lease from the foo | > > network using the bar wpakey. | > > | > > Solution: | > > | > > /etc/hostname.iwn0 | > > nwid foo | > > wpakey bar | > > dhcp | > > | > > Sets the network to foo and associates a password to it and then tries | > > to get a lease. | > > | > > Order matters. Perhaps there's a better way to phrase it but, as far as | > > guidance goes, I guess it's not quite possible to do that because | > > ifconfig alone has a plethora of possible usages. | > > | > | > does "dhcp nwid foo wpakey bar" give you problems too? because | > hostname.if(5) suggests it should not: | > | > A DHCP-configured network interface setup consists of | > | > dhcp options | | There have been problems reported with doing everything on one line in the | past. In this scenario 'options' may as well be called 'ifconfig-options'. | > | > so if it isn;t working, isn;t that indicative of a worse problem? or | > that we have not documented how "dhcp" works sufficiently? | | Not sure how much more we can document here. I'm actually wondering if it | wouldn't be more clear to eliminate the 'options' processing after 'dhcp', | i.e. make people do those things on separate, preceeding lines. Welcome to the pain that is 'do we break backwards compat?' There is a lot we could do if we could break backwards compat. | > we can;t just say order matters, but not provide any guidance. having | > said that, i think the text "The packed formats are converted", which i | > think deraadt added, was meant to address something like this. maybe he | > remembers? | | Well, hostname.if is simply a mechanism to script ifconfig invocations. If | you don't know in what order you need to issue the ifconfig invocations | required to configure your network, I'm not sure if hostname.if can | explain it in a reasonable amount of space. Indeed. The 'shorthand' or 'packed' syntax of hostname.if permits avoiding typing 'netmask' in the v4 case and 'prefixlen' in the v6 case, for example. | > anyway...i still dislike the idea of just saying order matters. also, | > could someone really expect the file to not be parsed top down (i don;t | > know, i'm just asking. it seems unlikely to me you'd start parsing from | > the end and work up)? | > | > jmc | > | | The misunderstanding I have seen run along the lines that all the | lines will be processed and then the system will issue a coherent set of | commands to achieve the described network. When really it is, as I said, | just a way to put all the ifconfig and related commands in one file. | | . Ken There is limited intelligence in the hostname.if parser implemented in sh. It passes things to ifconfig rather blindly and definitely does things in order without regards to any intelligence. If one were to have a hostname.if consist
Re: raw_usrreq - spl diff
We've discussed this with claudio and while there are might
be some other related issues with pr_usrreq and spls, I think
this particular diff needs to be committed. OK?
On Tue, Nov 13, 2012 at 14:18 -0500, David Hill wrote:
> Hello -
>
> I originally asked mikeb if splnet was needed in net/pfkey.c. He added
> onto my diff (which I have included below). I noticed route_usrreq from
> net/rtsock.c calls raw_usrreq protected by splsoftnet.
>
> I thought I'd send it to tech@ to possibly get more feedback.
>
> Here is the diff I am running with. I haven't had any regressions.
>
> Index: sys/net/pfkey.c
> ===
> RCS file: /cvs/src/sys/net/pfkey.c,v
> retrieving revision 1.19
> diff -N -u -p sys/net/pfkey.c
> --- sys/net/pfkey.c 20 Sep 2012 10:25:03 - 1.19
> +++ sys/net/pfkey.c 11 Nov 2012 01:18:42 -
> @@ -198,15 +198,12 @@ static int
> pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p)
> {
> int rval;
> - int s;
>
> if (!(socket->so_pcb = malloc(sizeof(struct rawcb),
> M_PCB, M_DONTWAIT | M_ZERO)))
> return (ENOMEM);
>
> - s = splnet();
> rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p);
> - splx(s);
> if (rval)
> goto ret;
>
> @@ -228,12 +225,10 @@ ret:
> static int
> pfkey_detach(struct socket *socket, struct proc *p)
> {
> - int rval, i, s;
> + int rval, i;
>
> rval = pfkey_versions[socket->so_proto->pr_protocol]->release(socket);
> - s = splnet();
> i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p);
> - splx(s);
>
> if (!rval)
> rval = i;
> @@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
> struct mbuf *nam, struct mbuf *control, struct proc *p)
> {
> int rval;
> - int s;
>
> if ((socket->so_proto->pr_protocol > PFKEY_PROTOCOL_MAX) ||
> (socket->so_proto->pr_protocol < 0) ||
> @@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
> return (pfkey_detach(socket, p));
>
> default:
> - s = splnet();
> rval = raw_usrreq(socket, req, mbuf, nam, control, p);
> - splx(s);
> }
>
> return (rval);
> Index: sys/net/raw_usrreq.c
> ===
> RCS file: /cvs/src/sys/net/raw_usrreq.c,v
> retrieving revision 1.14
> diff -N -u -p sys/net/raw_usrreq.c
> --- sys/net/raw_usrreq.c 11 Jan 2012 23:47:06 - 1.14
> +++ sys/net/raw_usrreq.c 11 Nov 2012 01:18:42 -
> @@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> {
> struct rawcb *rp = sotorawcb(so);
> int error = 0;
> - int len;
> + int len, s;
>
> if (req == PRU_CONTROL)
> return (EOPNOTSUPP);
> @@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> error = EINVAL;
> goto release;
> }
> + s = splsoftnet();
> switch (req) {
>
> /*
> @@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> /*
>* stat: don't bother with a blocksize.
>*/
> + splx(s);
> return (0);
>
> /*
> @@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
>*/
> case PRU_RCVOOB:
> case PRU_RCVD:
> + splx(s);
> return (EOPNOTSUPP);
>
> case PRU_LISTEN:
> @@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> panic("raw_usrreq");
> }
> release:
> + splx(s);
> if (m != NULL)
> m_freem(m);
> return (error);
Re: raw_usrreq - spl diff
Any thoughts?
On Tue, Nov 13, 2012 at 02:18:35PM -0500, David Hill wrote:
>Hello -
>
>I originally asked mikeb if splnet was needed in net/pfkey.c. He added
>onto my diff (which I have included below). I noticed route_usrreq from
>net/rtsock.c calls raw_usrreq protected by splsoftnet.
>
>I thought I'd send it to tech@ to possibly get more feedback.
>
>Here is the diff I am running with. I haven't had any regressions.
>
>Index: sys/net/pfkey.c
>===
>RCS file: /cvs/src/sys/net/pfkey.c,v
>retrieving revision 1.19
>diff -N -u -p sys/net/pfkey.c
>--- sys/net/pfkey.c20 Sep 2012 10:25:03 - 1.19
>+++ sys/net/pfkey.c11 Nov 2012 01:18:42 -
>@@ -198,15 +198,12 @@ static int
> pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p)
> {
> int rval;
>- int s;
>
> if (!(socket->so_pcb = malloc(sizeof(struct rawcb),
> M_PCB, M_DONTWAIT | M_ZERO)))
> return (ENOMEM);
>
>- s = splnet();
> rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p);
>- splx(s);
> if (rval)
> goto ret;
>
>@@ -228,12 +225,10 @@ ret:
> static int
> pfkey_detach(struct socket *socket, struct proc *p)
> {
>- int rval, i, s;
>+ int rval, i;
>
> rval = pfkey_versions[socket->so_proto->pr_protocol]->release(socket);
>- s = splnet();
> i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p);
>- splx(s);
>
> if (!rval)
> rval = i;
>@@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
> struct mbuf *nam, struct mbuf *control, struct proc *p)
> {
> int rval;
>- int s;
>
> if ((socket->so_proto->pr_protocol > PFKEY_PROTOCOL_MAX) ||
> (socket->so_proto->pr_protocol < 0) ||
>@@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
> return (pfkey_detach(socket, p));
>
> default:
>- s = splnet();
> rval = raw_usrreq(socket, req, mbuf, nam, control, p);
>- splx(s);
> }
>
> return (rval);
>Index: sys/net/raw_usrreq.c
>===
>RCS file: /cvs/src/sys/net/raw_usrreq.c,v
>retrieving revision 1.14
>diff -N -u -p sys/net/raw_usrreq.c
>--- sys/net/raw_usrreq.c 11 Jan 2012 23:47:06 - 1.14
>+++ sys/net/raw_usrreq.c 11 Nov 2012 01:18:42 -
>@@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> {
> struct rawcb *rp = sotorawcb(so);
> int error = 0;
>- int len;
>+ int len, s;
>
> if (req == PRU_CONTROL)
> return (EOPNOTSUPP);
>@@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> error = EINVAL;
> goto release;
> }
>+ s = splsoftnet();
> switch (req) {
>
> /*
>@@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> /*
>* stat: don't bother with a blocksize.
>*/
>+ splx(s);
> return (0);
>
> /*
>@@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
>*/
> case PRU_RCVOOB:
> case PRU_RCVD:
>+ splx(s);
> return (EOPNOTSUPP);
>
> case PRU_LISTEN:
>@@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
> panic("raw_usrreq");
> }
> release:
>+ splx(s);
> if (m != NULL)
> m_freem(m);
> return (error);
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 01:58:45PM -0500, Kenneth R Westerback wrote: > > > > does "dhcp nwid foo wpakey bar" give you problems too? because > > hostname.if(5) suggests it should not: > > > > A DHCP-configured network interface setup consists of > > > > dhcp options > > There have been problems reported with doing everything on one line in the > past. > > > > > so if it isn;t working, isn;t that indicative of a worse problem? or > > that we have not documented how "dhcp" works sufficiently? > > Not sure how much more we can document here. I'm actually wondering if it > wouldn't be more clear to eliminate the 'options' processing after 'dhcp', > i.e. make people do those things on separate, preceeding lines. > we should absolutely remove it if a) we're aware it causes problems and b) we think it makes sense to do it another way. the diff in your previous mail is actually better anyway - the info i was missing was i didn;t realise ifconfig got invoked separately for every line in hostname.if. > > > > we can;t just say order matters, but not provide any guidance. having > > said that, i think the text "The packed formats are converted", which i > > think deraadt added, was meant to address something like this. maybe he > > remembers? > > Well, hostname.if is simply a mechanism to script ifconfig invocations. If > you don't know in what order you need to issue the ifconfig invocations > required to configure your network, I'm not sure if hostname.if can > explain it in a reasonable amount of space. > but it's clear if we document that ifconfig is invoked separately with each line. > > > > anyway...i still dislike the idea of just saying order matters. also, > > could someone really expect the file to not be parsed top down (i don;t > > know, i'm just asking. it seems unlikely to me you'd start parsing from > > the end and work up)? > > > > jmc > > > > The misunderstanding I have seen run along the lines that all the > lines will be processed and then the system will issue a coherent set of > commands to achieve the described network. When really it is, as I said, > just a way to put all the ifconfig and related commands in one file. > i'm not sure i understand. but anyway i think your previous diff, plus removing the "dhcp options" recommendation, will be a decent start. jmc
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 05:40:06PM +, Jason McIntyre wrote: > On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: > > On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: > > > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: > > > > Be more specific about the order of interpretation. Okay? > > > > > > > > diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 > > > > index b07459f..aa8446f 100644 > > > > --- share/man/man5/hostname.if.5 > > > > +++ share/man/man5/hostname.if.5 > > > > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. > > > > The configuration information is expressed in a line-by-line packed > > > > format > > > > which makes the most common cases simpler; those dense formats are > > > > described > > > > below. > > > > +The order of the configuration lines matters, they are interpreted > > > > from the > > > > +top down. > > > > Any lines not matching these packed formats are passed directly to > > > > .Xr ifconfig 8 . > > > > The packed formats are converted using a somewhat inflexible parser and > > > > > > > > > > if we say this, then we should provide guidance to folks about how to > > > order the lines. what is the specific problem, or the general rule, that > > > you are addressing? > > > > Problem: > > > > /etc/hostname.iwn0: > > dhcp > > nwid foo > > wpakey bar > > > > Gets neighbour's lease then drops it then gets the lease from the foo > > network using the bar wpakey. > > > > Solution: > > > > /etc/hostname.iwn0 > > nwid foo > > wpakey bar > > dhcp > > > > Sets the network to foo and associates a password to it and then tries > > to get a lease. > > > > Order matters. Perhaps there's a better way to phrase it but, as far as > > guidance goes, I guess it's not quite possible to do that because > > ifconfig alone has a plethora of possible usages. > > > > does "dhcp nwid foo wpakey bar" give you problems too? because > hostname.if(5) suggests it should not: > > A DHCP-configured network interface setup consists of > > dhcp options There have been problems reported with doing everything on one line in the past. > > so if it isn;t working, isn;t that indicative of a worse problem? or > that we have not documented how "dhcp" works sufficiently? Not sure how much more we can document here. I'm actually wondering if it wouldn't be more clear to eliminate the 'options' processing after 'dhcp', i.e. make people do those things on separate, preceeding lines. > > we can;t just say order matters, but not provide any guidance. having > said that, i think the text "The packed formats are converted", which i > think deraadt added, was meant to address something like this. maybe he > remembers? Well, hostname.if is simply a mechanism to script ifconfig invocations. If you don't know in what order you need to issue the ifconfig invocations required to configure your network, I'm not sure if hostname.if can explain it in a reasonable amount of space. > > anyway...i still dislike the idea of just saying order matters. also, > could someone really expect the file to not be parsed top down (i don;t > know, i'm just asking. it seems unlikely to me you'd start parsing from > the end and work up)? > > jmc > The misunderstanding I have seen run along the lines that all the lines will be processed and then the system will issue a coherent set of commands to achieve the described network. When really it is, as I said, just a way to put all the ifconfig and related commands in one file. . Ken
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: > On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: > > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: > > > Be more specific about the order of interpretation. Okay? > > > > > > diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 > > > index b07459f..aa8446f 100644 > > > --- share/man/man5/hostname.if.5 > > > +++ share/man/man5/hostname.if.5 > > > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. > > > The configuration information is expressed in a line-by-line packed > > > format > > > which makes the most common cases simpler; those dense formats are > > > described > > > below. > > > +The order of the configuration lines matters, they are interpreted from > > > the > > > +top down. > > > Any lines not matching these packed formats are passed directly to > > > .Xr ifconfig 8 . > > > The packed formats are converted using a somewhat inflexible parser and > > > > > > > if we say this, then we should provide guidance to folks about how to > > order the lines. what is the specific problem, or the general rule, that > > you are addressing? > > Problem: > > /etc/hostname.iwn0: > dhcp > nwid foo > wpakey bar > > Gets neighbour's lease then drops it then gets the lease from the foo > network using the bar wpakey. > > Solution: > > /etc/hostname.iwn0 > nwid foo > wpakey bar > dhcp > > Sets the network to foo and associates a password to it and then tries > to get a lease. > > Order matters. Perhaps there's a better way to phrase it but, as far as > guidance goes, I guess it's not quite possible to do that because > ifconfig alone has a plethora of possible usages. > does "dhcp nwid foo wpakey bar" give you problems too? because hostname.if(5) suggests it should not: A DHCP-configured network interface setup consists of dhcp options so if it isn;t working, isn;t that indicative of a worse problem? or that we have not documented how "dhcp" works sufficiently? we can;t just say order matters, but not provide any guidance. having said that, i think the text "The packed formats are converted", which i think deraadt added, was meant to address something like this. maybe he remembers? anyway...i still dislike the idea of just saying order matters. also, could someone really expect the file to not be parsed top down (i don;t know, i'm just asking. it seems unlikely to me you'd start parsing from the end and work up)? jmc
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: > > Be more specific about the order of interpretation. Okay? > > > > diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 > > index b07459f..aa8446f 100644 > > --- share/man/man5/hostname.if.5 > > +++ share/man/man5/hostname.if.5 > > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. > > The configuration information is expressed in a line-by-line packed format > > which makes the most common cases simpler; those dense formats are > > described > > below. > > +The order of the configuration lines matters, they are interpreted from the > > +top down. > > Any lines not matching these packed formats are passed directly to > > .Xr ifconfig 8 . > > The packed formats are converted using a somewhat inflexible parser and > > > > if we say this, then we should provide guidance to folks about how to > order the lines. what is the specific problem, or the general rule, that > you are addressing? > > jmc > I suggest the following. I think the dhcp example is likely a common use case that is obvious and clear. Ken Index: hostname.if.5 === RCS file: /cvs/src/share/man/man5/hostname.if.5,v retrieving revision 1.56 diff -u -p -r1.56 hostname.if.5 --- hostname.if.5 8 Jul 2011 01:30:26 - 1.56 +++ hostname.if.5 26 Nov 2012 17:29:13 - @@ -63,6 +63,17 @@ For example: .Bd -literal -offset indent inet 10.0.0.1 255.255.255.0 10.0.0.255 description "Bob's uplink" .Ed +.Pp +Each line is processed separately and in order. +For example: +.Bd -literal -offset indent +nwid mynwid +wpakey mywpakey +dhcp +.Ed +.Pp +would run ifconfig to set the nwid of the interface, run it again to set the wpakey of the interface, and then start +.Xr dhclient 8 . .Sh STATIC ADDRESS CONFIGURATION The following packed formats are valid for configuring network interfaces with static addresses:
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: > > Be more specific about the order of interpretation. Okay? > > > > diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 > > index b07459f..aa8446f 100644 > > --- share/man/man5/hostname.if.5 > > +++ share/man/man5/hostname.if.5 > > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. > > The configuration information is expressed in a line-by-line packed format > > which makes the most common cases simpler; those dense formats are > > described > > below. > > +The order of the configuration lines matters, they are interpreted from the > > +top down. > > Any lines not matching these packed formats are passed directly to > > .Xr ifconfig 8 . > > The packed formats are converted using a somewhat inflexible parser and > > > > if we say this, then we should provide guidance to folks about how to > order the lines. what is the specific problem, or the general rule, that > you are addressing? Problem: /etc/hostname.iwn0: dhcp nwid foo wpakey bar Gets neighbour's lease then drops it then gets the lease from the foo network using the bar wpakey. Solution: /etc/hostname.iwn0 nwid foo wpakey bar dhcp Sets the network to foo and associates a password to it and then tries to get a lease. Order matters. Perhaps there's a better way to phrase it but, as far as guidance goes, I guess it's not quite possible to do that because ifconfig alone has a plethora of possible usages.
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 12:11 PM, Andres Perera wrote:
> don't know about OP, but yesterday i was surprised when rtlabel had to
> be specified after inet
just double checked; s/after/before
ifconfig(8) section on rtlabel bears no mention about the order
before rearranging, lines were just C sorted:
cat hostname.ral0
inet 192.168.2/24
rtlabel egress
afterboot:
route -vn show -inet | awk '{$2="";print}' | column -t
...
Destination Flags Refs Use MtuPrio Iface Label
default UGS4 557 - 12ral0
10.0.0/24 UC 1 0 - 4 re0
10.0.0.11 UHLc 3 1100 - 4 re0
127/8 UGRS 0 0 33152 8 lo0
127.0.0.1 UH 2 2433152 4 lo0
192.168.2/24 UC 1 0 - 4 ral0
192.168.2.1 UHLc 1 0 - 4 ral0
224/4 URS0 0 33152 8 lo0
>
> i haven't fully researched the relationship between the two, but at
> least during boot's run of netstart, this is a case where order of
> lines and thus ifconfig commands do matter
>
> On Mon, Nov 26, 2012 at 11:56 AM, Jason McIntyre wrote:
>> On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote:
>>> Be more specific about the order of interpretation. Okay?
>>>
>>> diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5
>>> index b07459f..aa8446f 100644
>>> --- share/man/man5/hostname.if.5
>>> +++ share/man/man5/hostname.if.5
>>> @@ -49,6 +49,8 @@ A configuration file is not needed for lo0.
>>> The configuration information is expressed in a line-by-line packed format
>>> which makes the most common cases simpler; those dense formats are
>>> described
>>> below.
>>> +The order of the configuration lines matters, they are interpreted from the
>>> +top down.
>>> Any lines not matching these packed formats are passed directly to
>>> .Xr ifconfig 8 .
>>> The packed formats are converted using a somewhat inflexible parser and
>>>
>>
>> if we say this, then we should provide guidance to folks about how to
>> order the lines. what is the specific problem, or the general rule, that
>> you are addressing?
>>
>> jmc
Re: hostname.if(5) clarification
don't know about OP, but yesterday i was surprised when rtlabel had to be specified after inet i haven't fully researched the relationship between the two, but at least during boot's run of netstart, this is a case where order of lines and thus ifconfig commands do matter On Mon, Nov 26, 2012 at 11:56 AM, Jason McIntyre wrote: > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: >> Be more specific about the order of interpretation. Okay? >> >> diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 >> index b07459f..aa8446f 100644 >> --- share/man/man5/hostname.if.5 >> +++ share/man/man5/hostname.if.5 >> @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. >> The configuration information is expressed in a line-by-line packed format >> which makes the most common cases simpler; those dense formats are described >> below. >> +The order of the configuration lines matters, they are interpreted from the >> +top down. >> Any lines not matching these packed formats are passed directly to >> .Xr ifconfig 8 . >> The packed formats are converted using a somewhat inflexible parser and >> > > if we say this, then we should provide guidance to folks about how to > order the lines. what is the specific problem, or the general rule, that > you are addressing? > > jmc
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: > Be more specific about the order of interpretation. Okay? > > diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 > index b07459f..aa8446f 100644 > --- share/man/man5/hostname.if.5 > +++ share/man/man5/hostname.if.5 > @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. > The configuration information is expressed in a line-by-line packed format > which makes the most common cases simpler; those dense formats are described > below. > +The order of the configuration lines matters, they are interpreted from the > +top down. > Any lines not matching these packed formats are passed directly to > .Xr ifconfig 8 . > The packed formats are converted using a somewhat inflexible parser and > if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? jmc
Re: ksh, add 'nobeep' option to disable bell
On lundi 26 novembre 2012 à 03:31:47, LEVAI Daniel wrote:
> Hi!
Hi,
> I needed an option to disable the bell in ksh, and I copied the idea of
> a 'nobeep' option from other shells.
[...]
What about a macro such as...
#define RING() do { if (!...) x_e_putc(BEL); } while (0)
...? Also, x_e_putc() seems to never be passed arbitrary strings
possibly containing BEL characters. So perhaps amending x_e_putc()
would be enough.
My two cents,
--
Jérémie Courrèges-Anglas
ksh, add 'nobeep' option to disable bell
Hi!
I needed an option to disable the bell in ksh, and I copied the idea of
a 'nobeep' option from other shells.
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.46
diff -p -u -r1.46 emacs.c
--- emacs.c 10 Jun 2012 10:15:01 - 1.46
+++ emacs.c 26 Nov 2012 14:25:51 -
@@ -399,7 +399,8 @@ x_insert(int c)
* Should allow tab and control chars.
*/
if (c == 0) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
str[0] = c;
@@ -421,7 +422,8 @@ static int
x_do_ins(const char *cp, int len)
{
if (xep+len >= xend) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return -1;
}
@@ -477,7 +479,8 @@ x_del_back(int c)
int col = xcp - xbuf;
if (col == 0) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
if (x_arg > col)
@@ -493,7 +496,8 @@ x_del_char(int c)
int nleft = xep - xcp;
if (!nleft) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
if (x_arg > nleft)
@@ -592,7 +596,8 @@ x_bword(void)
char*cp = xcp;
if (cp == xbuf) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return 0;
}
while (x_arg--) {
@@ -616,7 +621,8 @@ x_fword(void)
char*cp = xcp;
if (cp == xep) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return 0;
}
while (x_arg--) {
@@ -706,7 +712,8 @@ x_mv_back(int c)
int col = xcp - xbuf;
if (col == 0) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
if (x_arg > col)
@@ -721,7 +728,8 @@ x_mv_forw(int c)
int nleft = xep - xcp;
if (!nleft) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
if (x_arg > nleft)
@@ -741,7 +749,8 @@ x_search_char_forw(int c)
if (c < 0 ||
((cp = (cp == xep) ? NULL : strchr(cp + 1, c)) == NULL &&
(cp = strchr(xbuf, c)) == NULL)) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
}
@@ -760,7 +769,8 @@ x_search_char_back(int c)
if (p-- == xbuf)
p = xep;
if (c < 0 || p == cp) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
if (*p == c)
@@ -818,7 +828,8 @@ x_load_hist(char **hp)
int oldsize;
if (hp < history || hp > histptr) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return;
}
x_histp = hp;
@@ -902,7 +913,8 @@ x_search_hist(int c)
/* add char to pattern */
/* overflow check... */
if (p >= &pat[sizeof(pat) - 1]) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
continue;
}
*p++ = c, *p = '\0';
@@ -943,7 +955,8 @@ x_search(char *pat, int sameline, int of
return i;
}
}
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
x_histp = histptr;
return -1;
}
@@ -1082,11 +1095,13 @@ x_transpose(int c)
* to the one they want.
*/
if (xcp == xbuf) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
} else if (xcp == xep || Flag(FGMACS)) {
if (xcp - xbuf == 1) {
- x_e_putc(BEL);
+ if (!Flag(FNOBEEP))
+ x_e_putc(BEL);
return KSTD;
}
/* Gosling/Unipress emacs style: Swap two characters before the
@@ -1207,7 +1222,8 @@ x_abort(int c)
static int
x_error(int c)
{
- x_e_p
hostname.if(5) clarification
Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and
Re: audio hot keys
On Mon, Nov 26, 2012 at 12:21:03PM +0100, Alexandre Ratchov wrote:
> On Mon, Nov 26, 2012 at 11:55:15AM +0100, Matthieu Herrb wrote:
> > On Sun, Nov 25, 2012 at 08:17:06PM +0100, Alexandre Ratchov wrote:
> > > Currently audio hotkeys keys invoke the audio driver code to
> > > raise/lower the volume. The hot key is not consumed, and is send to
> > > X which generates XF86XK_Audio{Lower,Raise}Volume, which in turn
> > > are consumed by programs, which in turn change the volume a second
> > > time, and we end up with a messed volume. Furthermore hot keys are
> > > auto-repeated in X but on in the wskbd layer, which makes the
> > > volume changes even more confusing.
> > >
> > > IMO, we have to chose: either hot keys are consumed by the kernel
> > > to adjust the volume or they are passed to X.
> > >
> > > The diff below, is to make hot keys adjust the volume without
> > > propagating events to X.
> > >
> > > This can be tested on non-thinkpad and non-asus laptops. For
> > > instance start a video in mplayer and press the hot-keys; with this
> > > diff hot keys should adjust the hardware volume only instead of
> > > both the hardware volume and the mplayer softvol.
> >
> > That sounds generally sounds like a bad idea to me, altough I've no
> > idea how to solve that easily without a complex notification mechanism
> > and tons of policy... so it's probably ok for now.
>
> could you elaborate more; I'm not very aware of how X handles this;
> how are volume keys supposed to work to your opinion?
It's not specifically about X, and I'm not sure if generating X
keypress events is the best solution either.
I think it should behave like you describe it below, basically...
>
> >
> > will sio_onvol(3) be notified of changes done with the volume keys ?
>
> Not yet; the long term plan is make hotkeys (not necessarily the
> 174/176 keys which most keyboards lack) generate master volume MIDI
> events that sndiod could use (this way hotkeys work for the default
> device rather than the first one). This requires some thinking and
> I'm still not convinced it's the right thing to do.
yes, instead of handling the keys blindly inside the kernel, let them
generate some kind of event, that any daemon or application interested
in audio can receive and handle (or not). the "tons of policy" that
I'm referring to, is there to decide which of the event consumers will
actually change the volume, and may specify a fallback to in-kernel
processing if none is interested, or to generate keypress/release
events for X.
A sane default policy could of course be sending the events to
sndiod. But unless all ports doing audio are patched to use sndiod, we
should let some of them be able to get the events too.
Also some USB audio devices have volume control buttons that attach as
HID devices. Some attach as a HID keyboard and end up beeing handled
like the keyboard keys on the main keyboard, other attach as generic
HID and are thus left alone...
Now whith multiple devices, you may want to see the buttons on a USB
device control only the volume of that device too. That means that if
the devices attaches as HID keyboard, we should not allow it to attach
to the ws multiplexer, so that it's possible to match the input device
with the audio device... Again, policy...
--
Matthieu Herrb
Re: audio hot keys
On Mon, Nov 26, 2012 at 11:55:15AM +0100, Matthieu Herrb wrote:
> On Sun, Nov 25, 2012 at 08:17:06PM +0100, Alexandre Ratchov wrote:
> > Currently audio hotkeys keys invoke the audio driver code to
> > raise/lower the volume. The hot key is not consumed, and is send to
> > X which generates XF86XK_Audio{Lower,Raise}Volume, which in turn
> > are consumed by programs, which in turn change the volume a second
> > time, and we end up with a messed volume. Furthermore hot keys are
> > auto-repeated in X but on in the wskbd layer, which makes the
> > volume changes even more confusing.
> >
> > IMO, we have to chose: either hot keys are consumed by the kernel
> > to adjust the volume or they are passed to X.
> >
> > The diff below, is to make hot keys adjust the volume without
> > propagating events to X.
> >
> > This can be tested on non-thinkpad and non-asus laptops. For
> > instance start a video in mplayer and press the hot-keys; with this
> > diff hot keys should adjust the hardware volume only instead of
> > both the hardware volume and the mplayer softvol.
>
> That sounds generally sounds like a bad idea to me, altough I've no
> idea how to solve that easily without a complex notification mechanism
> and tons of policy... so it's probably ok for now.
could you elaborate more; I'm not very aware of how X handles this;
how are volume keys supposed to work to your opinion?
>
> will sio_onvol(3) be notified of changes done with the volume keys ?
Not yet; the long term plan is make hotkeys (not necessarily the
174/176 keys which most keyboards lack) generate master volume MIDI
events that sndiod could use (this way hotkeys work for the default
device rather than the first one). This requires some thinking and
I'm still not convinced it's the right thing to do.
-- Alexandre
Re: audio hot keys
On Sun, Nov 25, 2012 at 08:17:06PM +0100, Alexandre Ratchov wrote:
> Currently audio hotkeys keys invoke the audio driver code to
> raise/lower the volume. The hot key is not consumed, and is send to
> X which generates XF86XK_Audio{Lower,Raise}Volume, which in turn
> are consumed by programs, which in turn change the volume a second
> time, and we end up with a messed volume. Furthermore hot keys are
> auto-repeated in X but on in the wskbd layer, which makes the
> volume changes even more confusing.
>
> IMO, we have to chose: either hot keys are consumed by the kernel
> to adjust the volume or they are passed to X.
>
> The diff below, is to make hot keys adjust the volume without
> propagating events to X.
>
> This can be tested on non-thinkpad and non-asus laptops. For
> instance start a video in mplayer and press the hot-keys; with this
> diff hot keys should adjust the hardware volume only instead of
> both the hardware volume and the mplayer softvol.
That sounds generally sounds like a bad idea to me, altough I've no
idea how to solve that easily without a complex notification mechanism
and tons of policy... so it's probably ok for now.
will sio_onvol(3) be notified of changes done with the volume keys ?
--
Matthieu Herrb
