sysctl node names (Re: CVS commit: src/sys/uvm)
hi, > Module Name: src > Committed By: drochner > Date: Thu Feb 18 14:57:01 UTC 2010 > > Modified Files: > src/sys/uvm: files.uvm uvm_map.c > > Log Message: > Disable mapping of virtual address 0 by user programs per default. > This blocks an easy exploit of kernel bugs leading to dereference > of a NULL pointer on some architectures (eg i386). > The check can be disabled in various ways: > -by CPP definitions in machine/types.h (portmaster's choice) > -by a kernel config option USER_VA0_DISABLED_DEFAULT=0 > -at runtime by sysctl vm.user_va0_disabled (cannot be cleared > at securelevel>0) it reminded me this... can we have some policy for future sysctl node names? the current mixture of "enable" vs "enabled" seems ugly to me. if my preference matters, i'd say "enable"/"disable". YAMAMOTO Takashi ushi% sysctl -a|grep enable net.inet.tcp.sack.enable = 1 net.inet.tcp.ecn.enable = 0 net.inet.tcp.abc.enable = 1 net.inet6.tcp6.sack.enable = 1 net.inet6.tcp6.ecn.enable = 0 net.inet6.tcp6.abc.enable = 1 hw.fwohci.phydma_enable = 1 security.pax.mprotect.enabled = 1 security.pax.aslr.enabled = 1 ushi% > > > To generate a diff of this commit: > cvs rdiff -u -r1.16 -r1.17 src/sys/uvm/files.uvm > cvs rdiff -u -r1.287 -r1.288 src/sys/uvm/uvm_map.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files.
Re: DTrace port
The i386 platform is the platform of interest for my employer, hence its the first platform for the port. The FreeBSD port also has AMD64 support so that shouldn't be too difficult to add to NetBSD. br, Darran. On 15/02/2010, at 9:20 PM, Volker A. Brandt wrote: Courtesy of CoyotePoint Systems, I've been working on a port of DTrace (http://en.wikipedia.org/wiki/DTrace) to NetBSD for i386. The port is based on the FreeBSD-8 port and is close to the point where it would be useful to import it to current and make it available for any interested parties to experiment with it and, for example, add providers. Impressive! And very welcome news for NetBSD. Is there any specific reason why you focus on i386? Best regards -- Volker -- Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 45 Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
Re: btuart and SOCKET Bluetooth CF
On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
> Hi! Iain,
>
> From: Iain Hibbert
> Date: Thu, 18 Feb 2010 11:53:50 + (GMT)
>
> > On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
>
> > > > +static int
> > > > +btuart_dtl_probe(dev_t dev)
> > > > +{
> > > > +#if NCOM > 0
> > >:
> > > > +#endif
> > > > + return 0;
> > > > +}
> > > >
> > > > I really dislike this function, it depends on internals of com driver
> > > > [btw
> > > > COMUNIT(x) would be (minor(x) & COMUNIT_MASK)] and pcmcia and using this
> > > > method prevents a soft emulator and/or needs kernel modifications to
> > > > handle any new device.
> > >
> > > We are expecting the minor number to be obtained. In my opinion, it is
> > > necessary to open() the device node for that. Therefore, only minor()
> > > is called. It thinks dependence on the structure of pcmcia(4) for other
> > > way not to exist though it is very regrettable. ;-<
> >
> > I don't understand why you want to make it complex in this way?
> >
> > in the beginning, the admin must recognise that they have a Nokia DTL
> > device, eg:
> >
> > # btattach dtl /dev/tty03 19200
> >
> > btattach will perform the device specific initialisation, and set the line
> > to use the protocol that is required. Why do you desire to forget this
> > knowledge of the protocol type and require the btuart.c to depend on
> > possibly unrelated parts of the kernel to re-discover it later?
>
> hmm..
> I do not like to make new line disc for LSI named NOKIA DTL.
>
> > I find it makes no sense to do it that way, and furthermore the method
> > will cause problems for any user who wishes to use the Nokia DTL protocol
> > in a way that is not previously defined by you.
>
> To begin with, what is the NOKIA DTL protocol?
> NOKIA DTL is LSI.
I call it "protocol" because it is a method for communicating data between
devices using a certain encapsulation.
The "line discipline" is a filter that translates between the line
protocol and the protocol that the kernel is expecting.
That this protocol is only used by one device does not mean that it is
only for use by that device. Who is to say that it will not be used again
for another? How if somebody produces a USB->PCMCIA device that does not
expose the PCMCIA part and this device becomes connected as "com at ucom"?
I do not know if this is possible but I think it unwise to limit the
possibilities. Certainly it would be possible to have a software HCI
emulator using /dev/pty (perhaps to tunnel bluetooth connections over the
internet) but your method would refuse it to work with this protocol..
> We might separately make btdtl.c.
> # However, I will not make it...
I already agreed to integrate with btuart.c, but vastly simpler to provide
an .l_name = "btdtl" as was previously suggested..
iain
Re: enumeration of bicycle sheds
On Thu, Feb 18, 2010 at 05:43:15PM +0100, Alistair Crooks wrote: > On Thu, Feb 18, 2010 at 01:18:54PM +, Iain Hibbert wrote: > > actually caused warnings then I would be more inclined to use it. In the > > meantime, I generally prefer #define but am not greatly attached. > > whilst bicycles are a - particularly - sore point for me right now, > the reason that used to be proferred for preferring enums over #define > was the ability of symbolic debuggers to grok enums. ...and -g3 creates extremely large output. Joerg
Re: enumeration of bicycle sheds
On Thu, Feb 18, 2010 at 7:18 AM, Iain Hibbert wrote:
> On Thu, 18 Feb 2010, Terry Moore wrote:
>
>> Looking at C99, trailing commas _are_ allowed in enum lists.
>
> I know that, but C89 expressly forbade it and apparently C++ is similar.
> I'm not claiming that its reasonable and incidentally, share/misc/style
> says to not use the comma..
>
> If you or anybody wants to argue for or against enum vs #define for lists
> of internal state variables, please go ahead. If the type checking for
> enum was strong enough that
>
> enum val { FOO, BAR };
> int v = FOO;
>
> or
>
> enum val { FOO, BAR };
> enum val v = 3;
>
> actually caused warnings then I would be more inclined to use it. In the
> meantime, I generally prefer #define but am not greatly attached.
>
Debugging anything which uses #define is a major pita. That's why
people went to this and things like static const variables instead.
James
Re: enumeration of bicycle sheds
On Thu, Feb 18, 2010 at 01:18:54PM +, Iain Hibbert wrote: > actually caused warnings then I would be more inclined to use it. In the > meantime, I generally prefer #define but am not greatly attached. whilst bicycles are a - particularly - sore point for me right now, the reason that used to be proferred for preferring enums over #define was the ability of symbolic debuggers to grok enums. regards, alistair
Re: btuart and SOCKET Bluetooth CF
Looking at C99, trailing commas _are_ allowed in enum lists.
6.7.2.2 Enumeration specifiers
Syntax
1 enum-specifier:
enum identifieropt { enumerator-list }
enum identifieropt { enumerator-list , }
--Terry
t...@mcci.comtel: +1-607-277-1029fax: +1-607-277-6844www.mcci.com
On 2/18/2010 6:53 AM, Iain Hibbert wrote:
(btw, no comma is permitted on final enum values)
>
> This is because of convenient for the addition in the future. The diff
> becomes smaller.;-)
Yes, except C89 and C++ do not permit that, so gcc (also lint?) makes
complaints about it. It is not "reasonable" alas.
Re: enumeration of bicycle sheds
Sorry, misread original comment -- C89 appeared as C99. Old eyes can be
as bad as old ears for intelligent discussion
--Terry
t...@mcci.comtel: +1-607-277-1029fax: +1-607-277-6844www.mcci.com
On 2/18/2010 8:18 AM, Iain Hibbert wrote:
On Thu, 18 Feb 2010, Terry Moore wrote:
Looking at C99, trailing commas _are_ allowed in enum lists.
I know that, but C89 expressly forbade it and apparently C++ is similar.
I'm not claiming that its reasonable and incidentally, share/misc/style
says to not use the comma..
If you or anybody wants to argue for or against enum vs #define for lists
of internal state variables, please go ahead. If the type checking for
enum was strong enough that
enum val { FOO, BAR };
int v = FOO;
or
enum val { FOO, BAR };
enum val v = 3;
actually caused warnings then I would be more inclined to use it. In the
meantime, I generally prefer #define but am not greatly attached.
iain
Proposed changes to the dbcool(4) driver
Folks, When the dbcool(4) driver was commited, sysmon_envsys(9) did not have the ability to retrieve and set sensor limit values in the hardware device. As a result, dbcool had a separate user interface, using sysctl(8), for this purpose. Now that sysmon_envsys has grown the required capability (and it is actually working!), I'd like to remove the bulk of the sysctl interface from the dbcool driver, and provide that functionality using sysmon's capabilities. (I'll leave intact the ability to control the fan-speed PWM controllers, since there's still no viable alternative.) Does anyone see any reason to leave the sysctl interface in place? If we do leave it, can/should it be enabled/disabled using #define DBCOOL_SYSCTL ... #endif My preference would be to remove the sensor limit sysctl completely. - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
enumeration of bicycle sheds
On Thu, 18 Feb 2010, Terry Moore wrote:
> Looking at C99, trailing commas _are_ allowed in enum lists.
I know that, but C89 expressly forbade it and apparently C++ is similar.
I'm not claiming that its reasonable and incidentally, share/misc/style
says to not use the comma..
If you or anybody wants to argue for or against enum vs #define for lists
of internal state variables, please go ahead. If the type checking for
enum was strong enough that
enum val { FOO, BAR };
int v = FOO;
or
enum val { FOO, BAR };
enum val v = 3;
actually caused warnings then I would be more inclined to use it. In the
meantime, I generally prefer #define but am not greatly attached.
iain
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Thu, 18 Feb 2010 11:53:50 + (GMT)
> On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
> > > +static int
> > > +btuart_dtl_probe(dev_t dev)
> > > +{
> > > +#if NCOM > 0
> >:
> > > +#endif
> > > + return 0;
> > > +}
> > >
> > > I really dislike this function, it depends on internals of com driver [btw
> > > COMUNIT(x) would be (minor(x) & COMUNIT_MASK)] and pcmcia and using this
> > > method prevents a soft emulator and/or needs kernel modifications to
> > > handle any new device.
> >
> > We are expecting the minor number to be obtained. In my opinion, it is
> > necessary to open() the device node for that. Therefore, only minor()
> > is called. It thinks dependence on the structure of pcmcia(4) for other
> > way not to exist though it is very regrettable. ;-<
>
> I don't understand why you want to make it complex in this way?
>
> in the beginning, the admin must recognise that they have a Nokia DTL
> device, eg:
>
> # btattach dtl /dev/tty03 19200
>
> btattach will perform the device specific initialisation, and set the line
> to use the protocol that is required. Why do you desire to forget this
> knowledge of the protocol type and require the btuart.c to depend on
> possibly unrelated parts of the kernel to re-discover it later?
hmm..
I do not like to make new line disc for LSI named NOKIA DTL.
> I find it makes no sense to do it that way, and furthermore the method
> will cause problems for any user who wishes to use the Nokia DTL protocol
> in a way that is not previously defined by you.
To begin with, what is the NOKIA DTL protocol?
NOKIA DTL is LSI.
We might separately make btdtl.c.
# However, I will not make it...
Thanks,
--
kiyohara
Re: btuart and SOCKET Bluetooth CF
On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
+ if (m->m_pkthdr.len & 0x1) {
+ m_copyback(m, m->m_pkthdr.len, 1, &dtlh.rsvd); /* Add pad */
I wonder if handling this pad byte separately would be useful?
The reason I ask, is that as far as I recall, m_copyback() does always
extend the mbuf chain for additions such as this, even when there was some
trailing space (you might need to check, if this is still the case) and
you could perhaps optimise by not doing that..
regards,
iain
Re: btuart and SOCKET Bluetooth CF
On Thu, Feb 18, 2010 at 11:53:50AM +, Iain Hibbert wrote: > Yes, except C89 and C++ do not permit that, so gcc (also lint?) makes > complaints about it. It is not "reasonable" alas. Nitpick: C++ and C99 do allow it, gcc does not complain (at least I couldn't get it to complain with any -std= and -Wall value I tried). We should fix lint. Martin
Re: btuart and SOCKET Bluetooth CF
On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
> > (btw, no comma is permitted on final enum values)
>
> This is because of convenient for the addition in the future. The diff
> becomes smaller. ;-)
Yes, except C89 and C++ do not permit that, so gcc (also lint?) makes
complaints about it. It is not "reasonable" alas.
> > +static int
> > +btuart_dtl_probe(dev_t dev)
> > +{
> > +#if NCOM > 0
>:
> > +#endif
> > + return 0;
> > +}
> >
> > I really dislike this function, it depends on internals of com driver [btw
> > COMUNIT(x) would be (minor(x) & COMUNIT_MASK)] and pcmcia and using this
> > method prevents a soft emulator and/or needs kernel modifications to
> > handle any new device.
>
> We are expecting the minor number to be obtained. In my opinion, it is
> necessary to open() the device node for that. Therefore, only minor()
> is called. It thinks dependence on the structure of pcmcia(4) for other
> way not to exist though it is very regrettable. ;-<
I don't understand why you want to make it complex in this way?
in the beginning, the admin must recognise that they have a Nokia DTL
device, eg:
# btattach dtl /dev/tty03 19200
btattach will perform the device specific initialisation, and set the line
to use the protocol that is required. Why do you desire to forget this
knowledge of the protocol type and require the btuart.c to depend on
possibly unrelated parts of the kernel to re-discover it later?
I find it makes no sense to do it that way, and furthermore the method
will cause problems for any user who wishes to use the Nokia DTL protocol
in a way that is not previously defined by you.
regards,
iain
