sysv_ipc dropped clauses 3/4
It looks like copyright for sys/kern/sysv_ipc.c was assigned to NetBSD in rev 1.13 in 1998: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sysv_ipc.c.diff?r1=1.12&r2=1.13&only_with_tag=MAIN&f=h NetBSD then dropped clauses 3 & 4 in rev 1.21 in 2008: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sysv_ipc.c.diff?r1=1.20&r2=1.21&only_with_tag=MAIN&f=h Not sure if there's any interest in updating in OpenBSD...
Re: Fix profiling support in gcc 4.2
On Tue, 26 Mar 2013 16:39:54 -0700, Philip Guenther wrote:
> On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf wrote:
> ...
> >> Anyway, can we then just ignore the -pg option if it doesn't work for
> >> shared instead of breaking the link? Or do you have a better solution?
> >
> > I could do that (if I figure out the correct gcc specs), sure.
>
> Change this:
>%l %{pie:-pie} %{p|pg|nopie:-nopie}
>
> to this:
>%{pie:-pie} %{p|pg|nopie:-nopie} %l
>
> in the link_command spec.
That would require changing how LINK_PIE_SPEC is integrated into
LINK_COMMAND_SPEC, and it exploits the -nopie/-shared ordering nits I
mentioned, so I'm not a fan of that. I thought of something like this:
Index: gcc.c
===
RCS file: /home/pascal/cvs/src/gnu/gcc/gcc/gcc.c,v
retrieving revision 1.2
diff -u -p -r1.2 gcc.c
--- gcc.c 28 Aug 2012 18:59:28 - 1.2
+++ gcc.c 26 Mar 2013 23:29:00 -
@@ -684,7 +684,7 @@ proper position among the other output f
#ifndef LINK_PIE_SPEC
#ifdef HAVE_LD_PIE
-#define LINK_PIE_SPEC "%{pie:-pie} %{p|pg|nopie:-nopie} "
+#define LINK_PIE_SPEC "%{pie:-pie} %{!shared:%{p|pg:-nopie}} %{nopie:-nopie} "
#else
#define LINK_PIE_SPEC "%{pie:} "
#endif
> ...but I also like Mark's suggestion, to make -nopie not change the
> link mode (shared-object vs executable).
>
>
> Philip Guenther
>
>
Re: Fix profiling support in gcc 4.2
On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf wrote:
...
>> Anyway, can we then just ignore the -pg option if it doesn't work for
>> shared instead of breaking the link? Or do you have a better solution?
>
> I could do that (if I figure out the correct gcc specs), sure.
Change this:
%l %{pie:-pie} %{p|pg|nopie:-nopie}
to this:
%{pie:-pie} %{p|pg|nopie:-nopie} %l
in the link_command spec.
...but I also like Mark's suggestion, to make -nopie not change the
link mode (shared-object vs executable).
Philip Guenther
Re: Fix profiling support in gcc 4.2
On Tue, 26 Mar 2013 23:05:05 +0100 (CET), Mark Kettenis wrote: > > Date: Tue, 26 Mar 2013 23:54:20 +0200 > > From: Paul Irofti > > I don't understand how, can you go into more details please? > > > > Anyway, can we then just ignore the -pg option if it doesn't work for > > shared instead of breaking the link? Or do you have a better solution? > > Perhaps ld shouldn't set link_info.shared to FALSE when it sees -nopie? At the ld level, it basically breaks down to the question what the desired behaviour is when nonsensical combinations of -nopie and -shared are encountered. At the moment, -nopie cancels out a previously encountered -shared, so ld -shared -nopie ... will try to generate a non-shared, non-pie object, while ld -nopie -shared ... will behave the same as "ld -shared". I think this is the behaviour most people would expect, but I might be wrong. Other opinions?
Re: Fix profiling support in gcc 4.2
On Tue, 26 Mar 2013 23:54:20 +0200, Paul Irofti wrote: > On Tue, Mar 26, 2013 at 09:15:38PM +0100, Pascal Stumpf wrote: > > On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote: > > > Good evening everyone, > > > > > > I discovered about one or two weeks ago that I can't link any debug > > > libraries on OpenBSD. At first I thought it was a cmake update[1] but > > > then I started digging further and it turns out its our gcc. > > > > This is not about debug, but profiling libraries. > > Yes, I know that. As the email subject says. My debug libraries are also > compiled with profiling info. > > > > What threw me off is that gcc-4.7 from ports behaves the same way, but > > > I later discovered it's the same issue. > > > > > > Anyway, the problem pops up when doing something like this: > > > > > > --- > > > $ cc -shared -fpic -o libtest.so.0.0 `lorder test.so test1.so|tsort -q` > > > $ > > > --- > > > > > > versus something like this: > > > > > > --- > > > $ cc -shared -fpic -pg -o libtest.so.0.0 `lorder test.so test1.so|tsort > > > -q` > > > /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to > > > 00400260 > > > $ > > > --- > > > > > > This used to work in the past and no longer does on -current. > > > > It used to work in the sense that it produced a shared library with > > profiling and debug information. But this information is useless on > > OpenBSD. Profiling only works with static executables/libraries. > > Well, then perhaps just ignore the option when passed without nopie? You probably mean "with -shared". At the moment, -pg implies -nopie at the linking stage. > > Adding support for shared libraries would be non-trivial, and probably > > need support in ld.so. Look at sprof on Linux (even there, gprof > > doesn't support shared libraries). > > Interesting, I will, thanks! > > > The correct approach here is probably to error out when -pg is given in > > combination with -shared on OpenBSD. > > > > Have you seen this command line in a real-world build system? In that > > case, just disable -pg. > > Yes I did. I've been building this way for three years now. > > I would just set something like this, and it would work like a charm: > > set (CMAKE_CXX_FLAGS_DEBUG "-O0 -g -pg") > set (CMAKE_CXX_FLAGS_MINSIZEREL "-Os -DNDEBUG") > set (CMAKE_CXX_FLAGS_RELEASE"-O2 -DNDEBUG") > set (CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -DNDEBUG -g") > > But now, when I tried to build inside a clean object directory I ran > into this issue. Hmm, okay; but as far as I know, this will *never* produce a shared library that's actually suitable for being profiled. Even when using sprof on Linux, the documentation out there on the net suggests you should use -g, not -pg. So, if you actually want to build profiling (and not just debug) libraries, it takes more build system changes that just setting CFLAGS to -pg: You need to create a static library with a _p suffix instead of a shared one. > > > I tested on a 5.1 system and the last command links libtest properly > > > without an error. > > > > > > I tracked it down to the commit that enabled PIE support on OpenBSD. > > > > > > I looked at the specs from other operating systems and Linux > > > distributions and I haven't found any -nopie references not only in the > > > libs section, but throughout the entire spec. > > > > That's because nobody else has the -nopie option in ld. > > Okay. > > > > Thus I propose the following diff that removes the nopie bits. > > > > No, this would break linking profiled executables. > > I don't understand how, can you go into more details please? At the moment, profiling does not have PIC (or PIE) support. So everything compiled with profiling is non-PIE (-pg implies -fno-pie when compiling). The linker, however, defaults to -pie on all PIE archs. So it needs to be told to not try to generate a position-independent executable when dealing with profiling (which is exactly what the spec you proposed to remove does) or you end up with "could not use relocation foo when making a shared object" errors. > Anyway, can we then just ignore the -pg option if it doesn't work for > shared instead of breaking the link? Or do you have a better solution? I could do that (if I figure out the correct gcc specs), sure. > Thanks, > Paul Irofti > >
Re: Fix profiling support in gcc 4.2
> Date: Tue, 26 Mar 2013 23:54:20 +0200 > From: Paul Irofti > I don't understand how, can you go into more details please? > > Anyway, can we then just ignore the -pg option if it doesn't work for > shared instead of breaking the link? Or do you have a better solution? Perhaps ld shouldn't set link_info.shared to FALSE when it sees -nopie?
Re: Fix profiling support in gcc 4.2
On Tue, Mar 26, 2013 at 09:15:38PM +0100, Pascal Stumpf wrote: > On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote: > > Good evening everyone, > > > > I discovered about one or two weeks ago that I can't link any debug > > libraries on OpenBSD. At first I thought it was a cmake update[1] but > > then I started digging further and it turns out its our gcc. > > This is not about debug, but profiling libraries. Yes, I know that. As the email subject says. My debug libraries are also compiled with profiling info. > > What threw me off is that gcc-4.7 from ports behaves the same way, but > > I later discovered it's the same issue. > > > > Anyway, the problem pops up when doing something like this: > > > > --- > > $ cc -shared -fpic -o libtest.so.0.0 `lorder test.so test1.so|tsort -q` > > $ > > --- > > > > versus something like this: > > > > --- > > $ cc -shared -fpic -pg -o libtest.so.0.0 `lorder test.so test1.so|tsort > > -q` > > /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to > > 00400260 > > $ > > --- > > > > This used to work in the past and no longer does on -current. > > It used to work in the sense that it produced a shared library with > profiling and debug information. But this information is useless on > OpenBSD. Profiling only works with static executables/libraries. Well, then perhaps just ignore the option when passed without nopie? > Adding support for shared libraries would be non-trivial, and probably > need support in ld.so. Look at sprof on Linux (even there, gprof > doesn't support shared libraries). Interesting, I will, thanks! > The correct approach here is probably to error out when -pg is given in > combination with -shared on OpenBSD. > > Have you seen this command line in a real-world build system? In that > case, just disable -pg. Yes I did. I've been building this way for three years now. I would just set something like this, and it would work like a charm: set (CMAKE_CXX_FLAGS_DEBUG "-O0 -g -pg") set (CMAKE_CXX_FLAGS_MINSIZEREL "-Os -DNDEBUG") set (CMAKE_CXX_FLAGS_RELEASE"-O2 -DNDEBUG") set (CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -DNDEBUG -g") But now, when I tried to build inside a clean object directory I ran into this issue. > > I tested on a 5.1 system and the last command links libtest properly > > without an error. > > > > I tracked it down to the commit that enabled PIE support on OpenBSD. > > > > I looked at the specs from other operating systems and Linux > > distributions and I haven't found any -nopie references not only in the > > libs section, but throughout the entire spec. > > That's because nobody else has the -nopie option in ld. Okay. > > Thus I propose the following diff that removes the nopie bits. > > No, this would break linking profiled executables. I don't understand how, can you go into more details please? Anyway, can we then just ignore the -pg option if it doesn't work for shared instead of breaking the link? Or do you have a better solution? Thanks, Paul Irofti
Re: Fix profiling support in gcc 4.2
On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
> Good evening everyone,
>
> I discovered about one or two weeks ago that I can't link any debug
> libraries on OpenBSD. At first I thought it was a cmake update[1] but
> then I started digging further and it turns out its our gcc.
This is not about debug, but profiling libraries.
> What threw me off is that gcc-4.7 from ports behaves the same way, but
> I later discovered it's the same issue.
>
> Anyway, the problem pops up when doing something like this:
>
> ---
> $ cc -shared -fpic -o libtest.so.0.0 `lorder test.so test1.so|tsort -q`
> $
> ---
>
> versus something like this:
>
> ---
> $ cc -shared -fpic -pg -o libtest.so.0.0 `lorder test.so test1.so|tsort -q`
> /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
> 00400260
> $
> ---
>
> This used to work in the past and no longer does on -current.
It used to work in the sense that it produced a shared library with
profiling and debug information. But this information is useless on
OpenBSD. Profiling only works with static executables/libraries.
Adding support for shared libraries would be non-trivial, and probably
need support in ld.so. Look at sprof on Linux (even there, gprof
doesn't support shared libraries).
The correct approach here is probably to error out when -pg is given in
combination with -shared on OpenBSD.
Have you seen this command line in a real-world build system? In that
case, just disable -pg.
> I tested on a 5.1 system and the last command links libtest properly
> without an error.
>
> I tracked it down to the commit that enabled PIE support on OpenBSD.
>
> I looked at the specs from other operating systems and Linux
> distributions and I haven't found any -nopie references not only in the
> libs section, but throughout the entire spec.
That's because nobody else has the -nopie option in ld.
> Thus I propose the following diff that removes the nopie bits.
No, this would break linking profiled executables.
> An identical diff is needed for the ports tree and I will take care of
> it if this is accepted. So comments, okays?
>
> Cheers,
> Paul Irofti
>
>
> [1] -- http://marc.info/?l=openbsd-ports&m=136371733926696&w=2
>
> Index: gcc/gcc.c
> ===
> RCS file: /cvs/src/gnu/gcc/gcc/gcc.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 gcc.c
> --- gcc/gcc.c 28 Aug 2012 18:59:28 - 1.2
> +++ gcc/gcc.c 26 Mar 2013 19:33:05 -
> @@ -684,7 +684,7 @@ proper position among the other output f
>
> #ifndef LINK_PIE_SPEC
> #ifdef HAVE_LD_PIE
> -#define LINK_PIE_SPEC "%{pie:-pie} %{p|pg|nopie:-nopie} "
> +#define LINK_PIE_SPEC "%{pie:-pie} "
> #else
> #define LINK_PIE_SPEC "%{pie:} "
> #endif
>
>
Fix profiling support in gcc 4.2
Good evening everyone,
I discovered about one or two weeks ago that I can't link any debug
libraries on OpenBSD. At first I thought it was a cmake update[1] but
then I started digging further and it turns out its our gcc.
What threw me off is that gcc-4.7 from ports behaves the same way, but
I later discovered it's the same issue.
Anyway, the problem pops up when doing something like this:
---
$ cc -shared -fpic -o libtest.so.0.0 `lorder test.so test1.so|tsort -q`
$
---
versus something like this:
---
$ cc -shared -fpic -pg -o libtest.so.0.0 `lorder test.so test1.so|tsort -q`
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
00400260
$
---
This used to work in the past and no longer does on -current.
I tested on a 5.1 system and the last command links libtest properly
without an error.
I tracked it down to the commit that enabled PIE support on OpenBSD.
I looked at the specs from other operating systems and Linux
distributions and I haven't found any -nopie references not only in the
libs section, but throughout the entire spec.
Thus I propose the following diff that removes the nopie bits.
An identical diff is needed for the ports tree and I will take care of
it if this is accepted. So comments, okays?
Cheers,
Paul Irofti
[1] -- http://marc.info/?l=openbsd-ports&m=136371733926696&w=2
Index: gcc/gcc.c
===
RCS file: /cvs/src/gnu/gcc/gcc/gcc.c,v
retrieving revision 1.2
diff -u -p -r1.2 gcc.c
--- gcc/gcc.c 28 Aug 2012 18:59:28 - 1.2
+++ gcc/gcc.c 26 Mar 2013 19:33:05 -
@@ -684,7 +684,7 @@ proper position among the other output f
#ifndef LINK_PIE_SPEC
#ifdef HAVE_LD_PIE
-#define LINK_PIE_SPEC "%{pie:-pie} %{p|pg|nopie:-nopie} "
+#define LINK_PIE_SPEC "%{pie:-pie} "
#else
#define LINK_PIE_SPEC "%{pie:} "
#endif
Re: nfs pathconf
> > Let me explain my philosophy towards pathconf. It's like those > > configure scripts that check to see if you have a working version of > > strcpy. If you don't, you are so utterly boned you'll find out soon > > enough. If the nfs server isn't going to let you create a 255 > > character name, you'll find out soon enough. pathconf is one of those > > design by committee anti-portability features. It's silly it's even in > > the kernel. It should be a libc stub that whispers sweet nothings in > > your ear. > > So, does that make the case for fixing this in VOP_PATHCONF instead? > > Call the underlying filesystem call if it's there? and if not return the > "something sane" there? then we have our "something defaultly sane" > shit in one place? For some of the variables, you don't need to walk the path. For others, you do. Not enough axe murderers prowling the parking lots before austin group meetings.
Re: nfs pathconf
> Let me explain my philosophy towards pathconf. It's like those > configure scripts that check to see if you have a working version of > strcpy. If you don't, you are so utterly boned you'll find out soon > enough. If the nfs server isn't going to let you create a 255 > character name, you'll find out soon enough. pathconf is one of those > design by committee anti-portability features. It's silly it's even in > the kernel. It should be a libc stub that whispers sweet nothings in > your ear. So, does that make the case for fixing this in VOP_PATHCONF instead? Call the underlying filesystem call if it's there? and if not return the "something sane" there? then we have our "something defaultly sane" shit in one place? Just thinking outloud...
Re: goodbye to some isa devices
On Mar 26, 2013, at 11:11 PM, Creamy wrote: > On Tue, Mar 26, 2013 at 10:50:40PM +0400, Franco Fichtner wrote: >> Nobody in their right mind would have such a system as >> mission critical infrastructure. :) > > What, like using a Honeywell 316 as a nuclear power station > reactor temperature monitor in to the early 2000s, until it's > hard disk failed? > > Don't worry, it's been replaced with a couple of PDP11/70's, > so we can all sleep well at night. > > N.B. This one *isn't* a joke. Point taken; you are right. Scenario (3) is the most likely.
Re: nfs pathconf
On Tue, Mar 26, 2013 at 12:51, Bob Beck wrote: > On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt > wrote: >>> and doing EINVAL in the v2 case. >> >> Which won't solve the problem described in his mail. > > Of course it will - in the NFS v3 case, and in theory you'll be > getting what the server supports. > > I don't think we should go outside the nfs v2 spec and return values > we "hope are ok" in the nfs v2 case - remember here we're returning > the client values and hoping the server can support it. So what you're > saying is that it's better to return a potentially unsafe value, and > have filenames that a potential server might not handle? I'm not > buying that. in that special case of I'm running some software that Well, there's a certain amount of stupidity in pathconf already. PATH_MAX could cross a mount point and then become something else entirely. (Actually, that's an argument for factoring it up and handling it above the fs layer, but that's another diff.) > does this, I'd rather realize I'm running it on v2 that doesn't > support it by having it fail than just using the client side value and > "hope like heck it works out". Presumably, if I'm running v2, I'm > doing it for specefic reasons that v2 is better for and I know what > I'm doing. I'd rather not have the client start to do v3 like things > on v2 just so things "might work". - at that point I should be > noticing the error, and the fix is "mount it v3" Maybe you're using amd? hahaha. I don't think the nfs v2 spec demands that pathconf not work, it just doesn't support it because it didn't exist. Let me explain my philosophy towards pathconf. It's like those configure scripts that check to see if you have a working version of strcpy. If you don't, you are so utterly boned you'll find out soon enough. If the nfs server isn't going to let you create a 255 character name, you'll find out soon enough. pathconf is one of those design by committee anti-portability features. It's silly it's even in the kernel. It should be a libc stub that whispers sweet nothings in your ear.
Re: nfs pathconf
On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt wrote: >> and doing EINVAL in the v2 case. > > Which won't solve the problem described in his mail. Of course it will - in the NFS v3 case, and in theory you'll be getting what the server supports. I don't think we should go outside the nfs v2 spec and return values we "hope are ok" in the nfs v2 case - remember here we're returning the client values and hoping the server can support it. So what you're saying is that it's better to return a potentially unsafe value, and have filenames that a potential server might not handle? I'm not buying that. in that special case of I'm running some software that does this, I'd rather realize I'm running it on v2 that doesn't support it by having it fail than just using the client side value and "hope like heck it works out". Presumably, if I'm running v2, I'm doing it for specefic reasons that v2 is better for and I know what I'm doing. I'd rather not have the client start to do v3 like things on v2 just so things "might work". - at that point I should be noticing the error, and the fix is "mount it v3"
Re: goodbye to some isa devices
On Mar 26, 2013, at 10:06 PM, Creamy wrote: >>> Looking to the future, when are we going to drop 486 support, anyway? >> >> Now, that's a more interesting thing ask. > > How much of the hardware survives now, anyway? I mean at least the old > Vaxen were, (and are), maintainable. 486 motherboard dies, what do you > do? Chances are it's a multi-layer pcb, so if traces go bad within it, > a repair is going to be almost impossible. >From personal experience, the oldest things I've used *recently* was a Pentium Pro a few years back for providing Internet connectivity. That was when we barely had a single Mbit/s per line here in Germany. To be honest, it was about 8 years ago. I know a case study means nothing, so let me try another route. You would only need to upgrade to the latest and greatest release if one of the following is true: (1) Your system is connected to the Internet and thus requires frequent security updates. (2) You want to run services that are bleeding edge like OpenSMTPD out of the box. (3) You are crazy. But seriously, if there is no networking, there is no need to run a recent release. And you will be able to run 5.3 in any case. And why would you use networking anyway with such small throughput, the likelihood of your tiny IBM disk (a, those were the days!) failing on you any second now. All you've got there is a ticking time bomb. Nobody in their right mind would have such a system as mission critical infrastructure. :)
Re: goodbye to some isa devices
> If I'm testing hardware support and such, I'm going to want to get > thorough coverage of the drivers we build and purport to support. Next time mail in your dmesg! :) > I'd wager a bet that I could make my sea(4) scsi adapter work more > reliably than any variant of usb wi(4), so perhaps we should disable usb > wi(4) to save you time building instead? Actually, I deliberately excluded drivers with multiple bus attachments because the attachment shim is usually pretty small. Unless we're disabling wi at pcmcia too (and I don't think we are), there's not much point in removing just the usb part. Just for the record.
Re: nfs pathconf
On Tue, Mar 26, 2013 at 10:53 AM, Bob Beck wrote:
> Well, you're right about one thing - the comment there says that it should
> just return EINVAL for nfs v2 - and I think it should - but that code returns
> EINVAL for v3 - and that's wrong. We have server side support for this in v3
> and what we should probably be doing is actually doing the rpc call to the v3
> server in the v3 case and returning what it returns -
Sure, though nfsv3's pathconf call only supports a small subset of
pathconf() values:
struct nfsv3_pathconf {
u_int32_t pc_linkmax;
u_int32_t pc_namemax;
u_int32_t pc_notrunc;
u_int32_t pc_chownrestricted;
u_int32_t pc_caseinsensitive;
u_int32_t pc_casepreserving;
};
> and doing EINVAL in the v2 case.
I'm with tedu and Theo on this: giving best guess answers will provide
a better result than returning EINVAL.
Philip Guenther
Re: goodbye to some isa devices
Alexey E. Suslikov gmail.com> writes: > Not sure about ancient 3Com's, but they are Ethernet at > least, in contract to Token-Ring device like tr*. > > Do we support Token-Ring? Joystick driver?
Re: nfs pathconf
> and doing EINVAL in the v2 case. Which won't solve the problem described in his mail.
Re: nfs pathconf
Well, you're right about one thing - the comment there says that it should
just return EINVAL for nfs v2 - and I think it should - but that code returns
EINVAL for v3 - and that's wrong. We have server side support for this in v3
and what we should probably be doing is actually doing the rpc call to the v3
server in the v3 case and returning what it returns - and doing EINVAL
in the v2 case.
On Tue, Mar 26, 2013 at 1:12 AM, Ted Unangst wrote:
> After an absence of 9 years, I make my triumphant return to sys/nfs.
> There are some silly programs out there (looking at you boost) that
> actually use pathconf instead of just hard coding 1024 for max path
> length. If you run them from nfs, fireworks ensue.
>
> Here's a pathconf implementation for nfs, copied mostly from ufs. Even
> if some of these values are lies, they're better than nothing. My
> theory is that the values you care about (NAME_MAX, PATH_MAX) are
> going to be right, and the values you don't (REC_MAX_XFER_SIZE) are
> harmless even if incorrect.
>
> Index: nfs_vnops.c
> ===
> RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
> retrieving revision 1.140
> diff -u -p -r1.140 nfs_vnops.c
> --- nfs_vnops.c 17 Nov 2012 22:28:26 - 1.140
> +++ nfs_vnops.c 26 Mar 2013 07:04:53 -
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -2937,19 +2938,70 @@ loop:
>
> /*
> * Return POSIX pathconf information applicable to nfs.
> - *
> - * The NFS V2 protocol doesn't support this, so just return EINVAL
> - * for V2.
> */
> /* ARGSUSED */
> int
> nfs_pathconf(void *v)
> {
> -#if 0
> struct vop_pathconf_args *ap = v;
> -#endif
> + struct nfsmount *nmp = VFSTONFS(ap->a_vp->v_mount);
> + int error = 0;
>
> - return (EINVAL);
> + switch (ap->a_name) {
> + case _PC_LINK_MAX:
> + *ap->a_retval = LINK_MAX;
> + break;
> + case _PC_NAME_MAX:
> + *ap->a_retval = NAME_MAX;
> + break;
> + case _PC_PATH_MAX:
> + *ap->a_retval = PATH_MAX;
> + break;
> + case _PC_PIPE_BUF:
> + *ap->a_retval = PIPE_BUF;
> + break;
> + case _PC_CHOWN_RESTRICTED:
> + *ap->a_retval = 1;
> + break;
> + case _PC_NO_TRUNC:
> + *ap->a_retval = 1;
> + break;
> + case _PC_PRIO_IO:
> + *ap->a_retval = 0;
> + break;
> + case _PC_SYNC_IO:
> + *ap->a_retval = 0;
> + break;
> + case _PC_ALLOC_SIZE_MIN:
> + *ap->a_retval = NFS_FABLKSIZE;
> + break;
> + case _PC_FILESIZEBITS:
> + *ap->a_retval = 64;
> + break;
> + case _PC_REC_INCR_XFER_SIZE:
> + *ap->a_retval = min(nmp->nm_rsize, nmp->nm_wsize);
> + break;
> + case _PC_REC_MAX_XFER_SIZE:
> + *ap->a_retval = -1; /* means ``unlimited'' */
> + break;
> + case _PC_REC_MIN_XFER_SIZE:
> + *ap->a_retval = min(nmp->nm_rsize, nmp->nm_wsize);
> + break;
> + case _PC_REC_XFER_ALIGN:
> + *ap->a_retval = PAGE_SIZE;
> + break;
> + case _PC_SYMLINK_MAX:
> + *ap->a_retval = MAXPATHLEN;
> + break;
> + case _PC_2_SYMLINKS:
> + *ap->a_retval = 1;
> + break;
> + default:
> + error = EINVAL;
> + break;
> + }
> +
> + return (error);
> }
>
> /*
>
>
Re: goodbye to some isa devices
Todd T. Fries fries.net> writes: > I'd wager a bet that I could make my sea(4) scsi adapter work more > reliably than any variant of usb wi(4), so perhaps we should disable usb > wi(4) to save you time building instead? My 2 cents. Nuke tcic0 *and* pcic*: * searching archives bring dmesgs from 3.x/4.x era, * how big chances are to run 5.x on laptops with these PCMCIA controllers? Not sure about ancient 3Com's, but they are Ethernet at least, in contract to Token-Ring device like tr*. Do we support Token-Ring? Cheers, Alexey
Re: uvm combine clearbits
On Tue, Mar 26, 2013 at 10:55 AM, Miod Vallat wrote: >> > uvm_pagefree calls atomic_clearbits_int too many times. >> >> Is there some sort of evidence that this is a problem - performace or >> stability wise? > > Platforms which can't do ll/sc style atomic operations usually wrap > these operations within splhigh()/splx() calls, which are a tad > expensive. > > In that particular diff, Ted makes sure to flip the bits only during the > time the vm_page is not on any TAILQ, and before it is put on the free > list. > > This is narrow enough to me. > Yeah, ok, in light of that explanation I'm better with this. No objections here then.
Re: uvm combine clearbits
> > > uvm_pagefree calls atomic_clearbits_int too many times. > > > > Is there some sort of evidence that this is a problem - performace or > > stability wise? > > Platforms which can't do ll/sc style atomic operations usually wrap > these operations within splhigh()/splx() calls, which are a tad > expensive. > > In that particular diff, Ted makes sure to flip the bits only during the > time the vm_page is not on any TAILQ, and before it is put on the free > list. > > This is narrow enough to me. Same opinion.
Re: goodbye to some isa devices
> I don't think maintaining these drivers is currently a huge burden on > us. But decoupling them from the build will almost certainly lead to > some degree of bitrot. This 2nd sentence is the truth. At least when something is coupled to the build, it might warn us of the unintended consequences of something else in the tree. There is no point in half-disconnecting something from the tree; it is just leaving a mess for someone else down the line.
Re: goodbye to some isa devices
I really don't see the point of removing these from the tree. I just don't see greater value from removal, vs retention. Sure you can remove their compilation in GENERIC by #'ing them there. That I can understand. But if you remove the lines, noone can ever use them again because they won't know the locator information, so you are making a decision for others. Same thing with the stanzas in dev/isa/files.isa; if you remove those then noone else can ever use the code. If that is your goal, look at it this way. You talk about time. Removing them won't save you time; you just spent time looking for some of the bits, and your diff is nowhere near complete. There will be bits everywhere all the way through the tree all the way to the man pages, which you'll end up leaving for others, so others will be compelled to clean that up, and not do something else. That's a real time loss. I'm writing this mail, which is a time loss. Secondly, those drivers are not standing in the way of any changes in the tree. We are not changing any API they depend on. There are too many of these drivers to even consider changing an API that all of these drivers depend on, and you will not attritition them down to a manageable subset in any case. Third, we don't know if someone is running them or not. dmesglog is not authoritative.
Re: goodbye to some isa devices
On Mar 26, 2013, at 6:26 PM, Creamy wrote: >> but I honestly question the utility of any of these ISA >> network and SCSI drivers. > > Perhaps somebody who is new to coding might be able to learn something > from them? There is such a vast amount of code in the different BSD flavours alone that it becomes very unlikely someone will stumble upon ISA code bits, especially if one is a novice programmer. And how many of those are old enough to have seen what ISA looks like nowadays? Looking at diffs which remove ISA relevant stuff is probably the only time they will see it -- that's educational *and* teducational at the same time. Sorry for the bad pun. > Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask.
Re: uvm combine clearbits
> > uvm_pagefree calls atomic_clearbits_int too many times. > > Is there some sort of evidence that this is a problem - performace or > stability wise? Platforms which can't do ll/sc style atomic operations usually wrap these operations within splhigh()/splx() calls, which are a tad expensive. In that particular diff, Ted makes sure to flip the bits only during the time the vm_page is not on any TAILQ, and before it is put on the free list. This is narrow enough to me.
Re: goodbye to some isa devices
> These isa devs are already disabled and not particularly popular among > our users. affected: tcic, sea, wds, eg, el No objection against removing them from kernel configs (or commenting them out), but keep files.isa unchanged please.
Re: goodbye to some isa devices
Penned by Ted Unangst on 20130326 8:09.14, we have: | On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: | >> Date: Tue, 26 Mar 2013 05:20:27 -0400 | >> From: Ted Unangst | >> | >> These isa devs are already disabled and not particularly popular among | >> our users. affected: tcic, sea, wds, eg, el | > | > The reason these devices are disabled is probably that their probe | > routines are destructive. So the fact that they are disabled doesn't | > necessarily mean that they don't work properly. | > | > I don't think maintaining these drivers is currently a huge burden on | > us. But decoupling them from the build will almost certainly lead to | > some degree of bitrot. | | Perfection is achieved when there's nothing left to take away. :) | | It's not so much that we spend time maintaining the source, but I do | spend time compiling it. And I have to download it (3 times!) every | time I install a new snapshot. Cumulatively, I've probably spent hours | of my life waiting for these drivers' bits to go from here to there. I | will selfishly claim that if I save five minutes of time this year by | not compiling these files, that right there is more benefit than | retaining support. | | I targeted disabled devices figuring they were least likely to be | missed, but I honestly question the utility of any of these ISA | network and SCSI drivers. They're going to be slow as shit. Besides, | at this point, due to adding so many new drivers (kernel size has | more than doubled in last ten years) the minimum RAM requirement is | basically past ISA only machines. The segment of machines that lack | PCI but support 32M or more of RAM is very narrow. And unlike sparc or | vax, I don't think running OpenBSD on some ancient 486 is historically | interesting. I have some of these devices actually. Haven't used them in a few years, mainly due to office moves and boxes of unpacked unsorted stuff. I do clearly recall that it is useful to only enable some isa devices if one has them. I guess the question is, are we moving to a world where isa is not supported and/or supportable? Sure, if I'm doing build tests I'm going to load a box with mem and the fastest disks and nics I have. If I'm testing hardware support and such, I'm going to want to get thorough coverage of the drivers we build and purport to support. I'd wager a bet that I could make my sea(4) scsi adapter work more reliably than any variant of usb wi(4), so perhaps we should disable usb wi(4) to save you time building instead? Thanks, -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | "..in support of free software solutions." \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: goodbye to some isa devices
Sorry, but I think there is some seriously strange reasoning going on here. > It's not so much that we spend time maintaining the source, but I do > spend time compiling it. Err, don't you use a custom kernel configuration? Unless you're working on those drivers, why are you compiling them in anyway? Yes, I've read the FAQ, and I know we're all supposed to be using the GENERIC kernel, but who does? Mine is customisted beyond recognition. > And I have to download it (3 times!) every > time I install a new snapshot. Cumulatively, I've probably spent hours > of my life waiting for these drivers' bits to go from here to there. I > will selfishly claim that if I save five minutes of time this year by > not compiling these files, that right there is more benefit than > retaining support. There is certainly a case that five minutes multiplied by the number of OpenBSD users does add up to a significant amount of wasted time, but why are you assuming that these disabled by default drivers are not used by a significant number of people? > I targeted disabled devices figuring they were least likely to be > missed, I disagree here, there are plenty of enabled devices that nobody owns or cares about. The two issues are completely separate. > but I honestly question the utility of any of these ISA > network and SCSI drivers. Perhaps somebody who is new to coding might be able to learn something from them? > Besides, > at this point, due to adding so many new drivers (kernel size has > more than doubled in last ten years) the minimum RAM requirement is > basically past ISA only machines. This is an issue for the install media. After that, you should be running a custom kernel if you're using an obsolete machine. > The segment of machines that lack > PCI but support 32M or more of RAM is very narrow. True. > And unlike sparc or vax, I don't think running OpenBSD on some > ancient 486 is historically interesting. But OpenBSD doesn't run on the really interesting Vaxen, anyway. If it did, I'd have an 11-series Vax here tomorrow. I even have some 9-track tape in the loft, just waiting for it. The truth is, running OpenBSD on a MicroVax, is no more fun than an old 486, it's just slower. >>> boot loginout.exe oh, what nostalgia. Not. Have you ever used those machines, with their crashing removable disk packs. and tape drives that unwound 2400 feet of tape all over the place in just a few seconds? You're seeing them through rose-tinted glasses if you did. Not to mention that the decent Vaxen need three phase power. Great. Looking to the future, when are we going to drop 486 support, anyway? -- Creamy
Re: goodbye to some isa devices
> Date: Tue, 26 Mar 2013 09:09:14 -0400 > From: Ted Unangst > > On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: > >> Date: Tue, 26 Mar 2013 05:20:27 -0400 > >> From: Ted Unangst > >> > >> These isa devs are already disabled and not particularly popular among > >> our users. affected: tcic, sea, wds, eg, el > > > > The reason these devices are disabled is probably that their probe > > routines are destructive. So the fact that they are disabled doesn't > > necessarily mean that they don't work properly. > > > > I don't think maintaining these drivers is currently a huge burden on > > us. But decoupling them from the build will almost certainly lead to > > some degree of bitrot. > > Perfection is achieved when there's nothing left to take away. :) > > It's not so much that we spend time maintaining the source, but I do > spend time compiling it. And I have to download it (3 times!) every > time I install a new snapshot. Cumulatively, I've probably spent hours > of my life waiting for these drivers' bits to go from here to there. I > will selfishly claim that if I save five minutes of time this year by > not compiling these files, that right there is more benefit than > retaining support. > > I targeted disabled devices figuring they were least likely to be > missed, but I honestly question the utility of any of these ISA > network and SCSI drivers. They're going to be slow as shit. Besides, > at this point, due to adding so many new drivers (kernel size has > more than doubled in last ten years) the minimum RAM requirement is > basically past ISA only machines. The segment of machines that lack > PCI but support 32M or more of RAM is very narrow. And unlike sparc or > vax, I don't think running OpenBSD on some ancient 486 is historically > interesting. Probably true. I'm not necessarily opposed. Although it would make me sad if we didn't run on a machine that some other OS would still support.
write_opt=nodir support for ustar
Any objections for supporting write_opt=nodir for ustar archives?
Another option for Ruby gems will be going with GNU tar. :(
--
WBR,
Vadim Zhukov
Index: options.c
===
RCS file: /cvs/src/bin/pax/options.c,v
retrieving revision 1.76
diff -u -p -r1.76 options.c
--- options.c 4 Dec 2012 02:24:45 - 1.76
+++ options.c 26 Mar 2013 16:16:45 -
@@ -119,7 +119,7 @@ FSUB fsub[] = {
/* 5: POSIX USTAR */
{"ustar", 10240, BLKMULT, 0, 1, BLKMULT, 0, ustar_id, ustar_strd,
ustar_rd, tar_endrd, ustar_stwr, ustar_wr, tar_endwr, tar_trail,
- rd_wrfile, wr_rdfile, bad_opt},
+ rd_wrfile, wr_rdfile, tar_opt},
};
#defineF_OCPIO 0 /* format when called as cpio -6 */
#defineF_ACPIO 1 /* format when called as cpio -c */
Index: tar.c
===
RCS file: /cvs/src/bin/pax/tar.c,v
retrieving revision 1.44
diff -u -p -r1.44 tar.c
--- tar.c 4 Dec 2012 02:24:45 - 1.44
+++ tar.c 26 Mar 2013 16:16:45 -
@@ -914,6 +914,12 @@ ustar_wr(ARCHD *arcn)
}
/*
+* user asked that dirs not be written to the archive
+*/
+ if (arcn->type == PAX_DIR && tar_nodir)
+ return (1);
+
+ /*
* check the length of the linkname
*/
if (((arcn->type == PAX_SLK) || (arcn->type == PAX_HLK) ||
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 14:26, Creamy wrote: >> but I honestly question the utility of any of these ISA >> network and SCSI drivers. > > Perhaps somebody who is new to coding might be able to learn something > from them? The last thing this world needs is more programmers who learned to code by reading old unmaintained ISA drivers.
Re: uvm combine clearbits
On Tue, Mar 26, 2013 at 1:51 AM, Ted Unangst wrote:
> uvm_pagefree calls atomic_clearbits_int too many times.
Is there some sort of evidence that this is a problem - performace or
stability wise?
>Just
> accumulate the flags we need to zap, then do it once.
I get what you're trying to do, but given that there are already
enough cases of this in that code and you're now just making a few
special cases of saving the flag to avoid a few calls I don't think
it's worth the added "cleverness" in code that people like me have to
spend a lot of time wading through looking for errors - particularly
the types of errors that involve "can this sleep or not"... So I
don't personaly think this turdshining is worth it. I would
rather just see the bits set and know they are set just as in every other case.
>
> Index: uvm_page.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_page.c,v
> retrieving revision 1.122
> diff -u -p -r1.122 uvm_page.c
> --- uvm_page.c 12 Mar 2013 21:10:11 - 1.122
> +++ uvm_page.c 26 Mar 2013 07:45:56 -
> @@ -1053,6 +1053,7 @@ void
> uvm_pagefree(struct vm_page *pg)
> {
> int saved_loan_count = pg->loan_count;
> + u_int flags_to_clear = 0;
>
> #ifdef DEBUG
> if (pg->uobject == (void *)0xdeadbeef &&
> @@ -1115,7 +1116,7 @@ uvm_pagefree(struct vm_page *pg)
>
> if (pg->pg_flags & PQ_ACTIVE) {
> TAILQ_REMOVE(&uvm.page_active, pg, pageq);
> - atomic_clearbits_int(&pg->pg_flags, PQ_ACTIVE);
> + flags_to_clear |= PQ_ACTIVE;
> uvmexp.active--;
> }
> if (pg->pg_flags & PQ_INACTIVE) {
> @@ -1123,7 +1124,7 @@ uvm_pagefree(struct vm_page *pg)
> TAILQ_REMOVE(&uvm.page_inactive_swp, pg, pageq);
> else
> TAILQ_REMOVE(&uvm.page_inactive_obj, pg, pageq);
> - atomic_clearbits_int(&pg->pg_flags, PQ_INACTIVE);
> + flags_to_clear |= PQ_INACTIVE;
> uvmexp.inactive--;
> }
>
> @@ -1138,15 +1139,16 @@ uvm_pagefree(struct vm_page *pg)
> if (pg->uanon) {
> pg->uanon->an_page = NULL;
> pg->uanon = NULL;
> - atomic_clearbits_int(&pg->pg_flags, PQ_ANON);
> + flags_to_clear |= PQ_ANON;
> }
>
> /*
> * Clean page state bits.
> */
> - atomic_clearbits_int(&pg->pg_flags, PQ_AOBJ); /* XXX: find culprit */
> - atomic_clearbits_int(&pg->pg_flags, PQ_ENCRYPT|
> - PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|PG_CLEAN|PG_CLEANCHK);
> + flags_to_clear |= PQ_AOBJ; /* XXX: find culprit */
> + flags_to_clear |= PQ_ENCRYPT|PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|
> + PG_CLEAN|PG_CLEANCHK;
> + atomic_clearbits_int(&pg->pg_flags, flags_to_clear);
>
> /*
> * and put on free queue
>
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 09:09:14AM -0400, Ted Unangst wrote: > On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: > >> Date: Tue, 26 Mar 2013 05:20:27 -0400 > >> From: Ted Unangst > >> > >> These isa devs are already disabled and not particularly popular among > >> our users. affected: tcic, sea, wds, eg, el > > > > The reason these devices are disabled is probably that their probe > > routines are destructive. So the fact that they are disabled doesn't > > necessarily mean that they don't work properly. > > > > I don't think maintaining these drivers is currently a huge burden on > > us. But decoupling them from the build will almost certainly lead to > > some degree of bitrot. > > Perfection is achieved when there's nothing left to take away. :) > > It's not so much that we spend time maintaining the source, but I do > spend time compiling it. And I have to download it (3 times!) every > time I install a new snapshot. Cumulatively, I've probably spent hours > of my life waiting for these drivers' bits to go from here to there. I > will selfishly claim that if I save five minutes of time this year by > not compiling these files, that right there is more benefit than > retaining support. > > I targeted disabled devices figuring they were least likely to be > missed, but I honestly question the utility of any of these ISA > network and SCSI drivers. They're going to be slow as shit. Besides, > at this point, due to adding so many new drivers (kernel size has > more than doubled in last ten years) the minimum RAM requirement is > basically past ISA only machines. The segment of machines that lack > PCI but support 32M or more of RAM is very narrow. And unlike sparc or > vax, I don't think running OpenBSD on some ancient 486 is historically > interesting. > The ISA SCSI drivers have certainly received no love from me as a deliberate policy. This of course may be good or bad for their functionality. :-) And then there are the EISA SCSI drivers. Ken
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 5:09 PM, Ted Unangst wrote: > On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: >>> Date: Tue, 26 Mar 2013 05:20:27 -0400 >>> From: Ted Unangst >>> >>> These isa devs are already disabled and not particularly popular among >>> our users. affected: tcic, sea, wds, eg, el >> >> The reason these devices are disabled is probably that their probe >> routines are destructive. So the fact that they are disabled doesn't >> necessarily mean that they don't work properly. >> >> I don't think maintaining these drivers is currently a huge burden on >> us. But decoupling them from the build will almost certainly lead to >> some degree of bitrot. > > Perfection is achieved when there's nothing left to take away. :) > > It's not so much that we spend time maintaining the source, but I do > spend time compiling it. And I have to download it (3 times!) every > time I install a new snapshot. Cumulatively, I've probably spent hours > of my life waiting for these drivers' bits to go from here to there. I > will selfishly claim that if I save five minutes of time this year by > not compiling these files, that right there is more benefit than > retaining support. > > I targeted disabled devices figuring they were least likely to be > missed, but I honestly question the utility of any of these ISA > network and SCSI drivers. They're going to be slow as shit. Besides, > at this point, due to adding so many new drivers (kernel size has > more than doubled in last ten years) the minimum RAM requirement is > basically past ISA only machines. The segment of machines that lack > PCI but support 32M or more of RAM is very narrow. And unlike sparc or > vax, I don't think running OpenBSD on some ancient 486 is historically > interesting. > I still run OpenBSD as a wireless AP on a pentium-1 166Mhz with 48Mb RAM, and 3 PCI cards. ISA sound card was removed :-) -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light !
Re: uthum(4): Microdia's USB TEMPer variant
Hello, Luis. Now I am rewriting a driver for Microdia's USB TEMPer with advices from yuo@ and deraadt@. Please wait a while and thank you for trying my patch. Thanks. -- SASANO Takayoshi
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: >> Date: Tue, 26 Mar 2013 05:20:27 -0400 >> From: Ted Unangst >> >> These isa devs are already disabled and not particularly popular among >> our users. affected: tcic, sea, wds, eg, el > > The reason these devices are disabled is probably that their probe > routines are destructive. So the fact that they are disabled doesn't > necessarily mean that they don't work properly. > > I don't think maintaining these drivers is currently a huge burden on > us. But decoupling them from the build will almost certainly lead to > some degree of bitrot. Perfection is achieved when there's nothing left to take away. :) It's not so much that we spend time maintaining the source, but I do spend time compiling it. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. I targeted disabled devices figuring they were least likely to be missed, but I honestly question the utility of any of these ISA network and SCSI drivers. They're going to be slow as shit. Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting.
Re: goodbye to some isa devices
> Date: Tue, 26 Mar 2013 05:20:27 -0400 > From: Ted Unangst > > These isa devs are already disabled and not particularly popular among > our users. affected: tcic, sea, wds, eg, el The reason these devices are disabled is probably that their probe routines are destructive. So the fact that they are disabled doesn't necessarily mean that they don't work properly. I don't think maintaining these drivers is currently a huge burden on us. But decoupling them from the build will almost certainly lead to some degree of bitrot. > Index: arch/i386/conf/GENERIC > === > RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v > retrieving revision 1.744 > diff -u -p -r1.744 GENERIC > --- arch/i386/conf/GENERIC15 Mar 2013 09:10:52 - 1.744 > +++ arch/i386/conf/GENERIC26 Mar 2013 08:20:40 - > @@ -188,7 +188,6 @@ nvt* at iic? # Novoton > W83795G > pcic0at isa? port 0x3e0 iomem 0xd iosiz 0x1 > pcic1at isa? port 0x3e2 iomem 0xe iosiz 0x4000 > pcic2at isa? port 0x3e4 iomem 0xe iosiz 0x4000 > -tcic0at isa? disable port 0x240 iomem 0xd iosiz 0x1 > > # ISA Plug-and-Play PCMCIA controllers > #option DEBUG_ISAPNP > @@ -199,7 +198,6 @@ pcic* at pci? > > # PCMCIA bus support > pcmcia* at pcic? > -pcmcia* at tcic? > > # CardBus bus support > cardbus* at cardslot? > @@ -464,13 +462,10 @@ siop* at pci? # NCR 538XX SCSI control > adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI > adw* at pci? # AdvanSys ULTRA WIDE SCSI > pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI > -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers > trm* at pci? # Tekram DC-3x5U SCSI Controllers > uha0 at isa? port 0x330 # UltraStor [13]4f SCSI controllers > uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers > uha* at eisa?# UltraStor 24f SCSI controllers > -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 > controllers > -#wds1at isa? port 0x358 irq 11 drq 5 > > scsibus* at scsi? > sd* at scsibus? # SCSI disk drives > @@ -511,8 +506,6 @@ ne0 at isa? port 0x240 irq 9# > NE[12]00 > ne1 at isa? port 0x300 irq 10 # NE[12]000 ethernet > ne2 at isa? port 0x280 irq 9# NE[12]000 ethernet > ne* at isapnp? # NE[12]000 PnP ethernet > -eg0 at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet > -el0 at isa? disable port 0x300 irq 9# 3C501 ethernet > ep0 at isa? # 3C509 ethernet > ep* at isapnp? # 3C509 PnP ethernet > ep* at isa? # 3C509 ethernet > Index: arch/i386/conf/RAMDISK_CD > === > RCS file: /cvs/src/sys/arch/i386/conf/RAMDISK_CD,v > retrieving revision 1.194 > diff -u -p -r1.194 RAMDISK_CD > --- arch/i386/conf/RAMDISK_CD 16 Nov 2012 02:15:38 - 1.194 > +++ arch/i386/conf/RAMDISK_CD 26 Mar 2013 08:19:13 - > @@ -223,13 +223,11 @@ siop* at pci? # NCR 538XX SCSI control > adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI > adw* at pci? # AdvanSys ULTRA WIDE SCSI > pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI > -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI > controllers > trm* at pci? # Tekram DC-3x5U SCSI Controllers > uha0 at isa? port 0x330 # UltraStor [13]4f SCSI controllers > uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers > uha* at eisa?# UltraStor 24f SCSI controllers > -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 > controllers > -#wds1at isa? port 0x358 irq 11 drq 5 > + > softraid0at root # Software RAID > > # I2O > @@ -272,8 +270,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]000 > ne1 at isa? port 0x300 irq 10 # NE[12]000 ethernet > ne2 at isa? port 0x280 irq 9# NE[12]000 ethernet > ne* at isapnp? # NE[12]000 PnP ethernet > -eg0 at isa? disable port 0x310 irq 5 # 3C505/Etherlink+ ethernet > -el0 at isa? disable port 0x300 irq 9 # 3C501 ethernet > ep0 at isa? # 3C509 ethernet > ep* at isa? # 3C509 ethernet > ep* at isapnp? # 3C509 PnP ethernet > Index: arch/i386/conf/files.i386 > === > RCS file: /cvs/src/sys/arch/i386/conf/files.i386,v > retrieving revision 1.211 > diff -u -p -r1.211 files.i386 > --- arch/i386/conf/files.i386 6 Sep 2012 20:20:30 - 1.211 > +++ arch/i386/conf/files.i386 26 Mar 2013
Re: Intel D945GPT on recently built -current running with framebuffer and all VCONs
I have sent the previous message to dmesg@ and to this list so that the involved devs can see that not only the Intel 915 stuff works but so does the D945. Hope this is useful to jsg@ & co. Rod/ *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Intel D945GPT on recently built -current running with framebuffer & all VCONs
OpenBSD 5.3-current (GENERIC) #11: Tue Mar 26 13:32:47 EST 2013
r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) D CPU 3.20GHz ("GenuineIntel" 686-class) 3.21 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,PDCM,LAHF
real mem = 1063272448 (1014MB)
avail mem = 1034477568 (986MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/04/07, SMBIOS rev. 2.3 @ 0xe5410 (31
entries)
bios0: vendor Intel Corp. version "NT94510J.86A.4078.2007.0504.0047" date
05/04/2007
bios0: Intel Corporation D945GTP
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC WDDT MCFG ASF! HPET SSDT
acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S4) UAR2(S4) PEX0(S4) PEX1(S4)
PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3)
EHCI(S3) AC9M(S4) AZAL(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P32_)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus -1 (PEX1)
acpiprt4 at acpi0: bus 2 (PEX2)
acpiprt5 at acpi0: bus 3 (PEX3)
acpiprt6 at acpi0: bus -1 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpicpu0 at acpi0
acpibtn0 at acpi0: SLPB
bios0: ROM list: 0xc/0xae00!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0x4000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: apic 2 int 16
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 2 int 17
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: apic 2 int 18
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 2 int 19
pci3 at ppb2 bus 3
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci4 at ppb3 bus 4
fxp0 at pci4 dev 8 function 0 "Intel 82801GB LAN" rev 0x01, i82562: apic 2 int
20, address 00:16:76:90:35:68
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 ignored (disabled)
pciide1 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 2 int 19 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 2 int 19
iic0 at ichiic0
adt0 at iic0 addr 0x2e: emc6d100 rev 0x68
spdmem0 at iic0 addr 0x50: 512MB DDR2 SDRAM non-parity PC2-5300CL5
spdmem1 at iic0 addr 0x52: 512MB DDR2 SDRAM non-parity PC2-5300CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 ir
Re: rename NCHNAMLEN
On Tue, Mar 26, 2013 at 10:09, Mark Kettenis wrote:
>> Date: Tue, 26 Mar 2013 05:03:59 -0400
>> From: Ted Unangst
>>
>> it's 2013. we don't have to pay extra for vowels.
>
> Even in 2013, my terminals are still 80 columns wide. This makes some
> of the lines wrap. Not really an improvement if you ask me.
oops, sorry, mine were a little wider and i didn't notice. easy to fix.
besides improving readability (imo), i find it much easier typing real
words, even if they're a little longer. i can visually confirm that
i'm actually grepping for the identifier used by the code and not some
subtly transposed variant.
Index: kern/vfs_cache.c
===
RCS file: /cvs/src/sys/kern/vfs_cache.c,v
retrieving revision 1.34
diff -u -p -r1.34 vfs_cache.c
--- kern/vfs_cache.c4 Jan 2012 18:11:51 - 1.34
+++ kern/vfs_cache.c26 Mar 2013 08:59:59 -
@@ -48,7 +48,7 @@
/*
* For simplicity (and economy of storage), names longer than
- * a maximum length of NCHNAMLEN are not cached; they occur
+ * a maximum length of NAMECACHE_MAXLEN are not cached; they occur
* infrequently in any case, and are almost never of interest.
*
* Upon reaching the last segment of a path, if the reference
@@ -148,7 +148,7 @@ cache_lookup(struct vnode *dvp, struct v
cnp->cn_flags &= ~MAKEENTRY;
return (-1);
}
- if (cnp->cn_namelen > NCHNAMLEN) {
+ if (cnp->cn_namelen > NAMECACHE_MAXLEN) {
nchstats.ncs_long++;
cnp->cn_flags &= ~MAKEENTRY;
return (-1);
@@ -342,7 +342,7 @@ cache_enter(struct vnode *dvp, struct vn
{
struct namecache *ncp, *lncp;
- if (!doingcache || cnp->cn_namelen > NCHNAMLEN)
+ if (!doingcache || cnp->cn_namelen > NAMECACHE_MAXLEN)
return;
/*
Index: sys/namei.h
===
RCS file: /cvs/src/sys/sys/namei.h,v
retrieving revision 1.27
diff -u -p -r1.27 namei.h
--- sys/namei.h 30 Sep 2011 03:43:27 - 1.27
+++ sys/namei.h 26 Mar 2013 09:23:43 -
@@ -165,7 +165,7 @@ struct nameidata {
* names looked up by namei.
*/
-#defineNCHNAMLEN 31 /* maximum name segment length we
bother with */
+#defineNAMECACHE_MAXLEN 31 /* maximum name segment length we bother
with */
struct namecache {
TAILQ_ENTRY(namecache) nc_lru; /* Regular Entry LRU chain */
@@ -177,7 +177,7 @@ struct namecache {
struct vnode *nc_vp; /* vnode the name refers to */
u_long nc_vpid;/* capability number of nc_vp */
charnc_nlen;/* length of name */
- charnc_name[NCHNAMLEN]; /* segment name */
+ charnc_name[NAMECACHE_MAXLEN]; /* segment name */
};
#ifdef _KERNEL
Index: nfs/nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs/nfs_vnops.c 17 Nov 2012 22:28:26 - 1.140
+++ nfs/nfs_vnops.c 26 Mar 2013 09:22:26 -
@@ -2455,7 +2456,8 @@ nfs_readdirplusrpc(struct vnode *vp, str
info.nmi_md = mdsav2;
dp->d_type = IFTODT(
VTTOIF(np->n_vattr.va_type));
- if (cnp->cn_namelen <= NCHNAMLEN) {
+ if (cnp->cn_namelen <=
+ NAMECACHE_MAXLEN) {
ndp->ni_vp = newvp;
cache_purge(ndp->ni_dvp);
nfs_cache_enter(ndp->ni_dvp,
goodbye to some isa devices
These isa devs are already disabled and not particularly popular among our users. affected: tcic, sea, wds, eg, el Index: arch/i386/conf/GENERIC === RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v retrieving revision 1.744 diff -u -p -r1.744 GENERIC --- arch/i386/conf/GENERIC 15 Mar 2013 09:10:52 - 1.744 +++ arch/i386/conf/GENERIC 26 Mar 2013 08:20:40 - @@ -188,7 +188,6 @@ nvt*at iic? # Novoton W83795G pcic0 at isa? port 0x3e0 iomem 0xd iosiz 0x1 pcic1 at isa? port 0x3e2 iomem 0xe iosiz 0x4000 pcic2 at isa? port 0x3e4 iomem 0xe iosiz 0x4000 -tcic0 at isa? disable port 0x240 iomem 0xd iosiz 0x1 # ISA Plug-and-Play PCMCIA controllers #option DEBUG_ISAPNP @@ -199,7 +198,6 @@ pcic* at pci? # PCMCIA bus support pcmcia*at pcic? -pcmcia* at tcic? # CardBus bus support cardbus* at cardslot? @@ -464,13 +462,10 @@ siop* at pci? # NCR 538XX SCSI control adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI adw* at pci? # AdvanSys ULTRA WIDE SCSI pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers trm* at pci? # Tekram DC-3x5U SCSI Controllers uha0 at isa? port 0x330 # UltraStor [13]4f SCSI controllers uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers uha* at eisa?# UltraStor 24f SCSI controllers -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 controllers -#wds1 at isa? port 0x358 irq 11 drq 5 scsibus* at scsi? sd*at scsibus? # SCSI disk drives @@ -511,8 +506,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]00 ne1at isa? port 0x300 irq 10 # NE[12]000 ethernet ne2at isa? port 0x280 irq 9# NE[12]000 ethernet ne*at isapnp? # NE[12]000 PnP ethernet -eg0at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet -el0at isa? disable port 0x300 irq 9# 3C501 ethernet ep0at isa? # 3C509 ethernet ep*at isapnp? # 3C509 PnP ethernet ep*at isa? # 3C509 ethernet Index: arch/i386/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/i386/conf/RAMDISK_CD,v retrieving revision 1.194 diff -u -p -r1.194 RAMDISK_CD --- arch/i386/conf/RAMDISK_CD 16 Nov 2012 02:15:38 - 1.194 +++ arch/i386/conf/RAMDISK_CD 26 Mar 2013 08:19:13 - @@ -223,13 +223,11 @@ siop* at pci? # NCR 538XX SCSI control adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI adw* at pci? # AdvanSys ULTRA WIDE SCSI pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers trm* at pci? # Tekram DC-3x5U SCSI Controllers uha0 at isa? port 0x330 # UltraStor [13]4f SCSI controllers uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers uha* at eisa?# UltraStor 24f SCSI controllers -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 controllers -#wds1 at isa? port 0x358 irq 11 drq 5 + softraid0 at root # Software RAID # I2O @@ -272,8 +270,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]000 ne1at isa? port 0x300 irq 10 # NE[12]000 ethernet ne2at isa? port 0x280 irq 9# NE[12]000 ethernet ne*at isapnp? # NE[12]000 PnP ethernet -eg0at isa? disable port 0x310 irq 5 # 3C505/Etherlink+ ethernet -el0at isa? disable port 0x300 irq 9 # 3C501 ethernet ep0at isa? # 3C509 ethernet ep*at isa? # 3C509 ethernet ep*at isapnp? # 3C509 PnP ethernet Index: arch/i386/conf/files.i386 === RCS file: /cvs/src/sys/arch/i386/conf/files.i386,v retrieving revision 1.211 diff -u -p -r1.211 files.i386 --- arch/i386/conf/files.i386 6 Sep 2012 20:20:30 - 1.211 +++ arch/i386/conf/files.i386 26 Mar 2013 08:19:33 - @@ -362,12 +362,6 @@ file dev/isa/i82365_isapnp.c pcic_isapnp # Code common to ISA and ISAPnP attachments file dev/isa/i82365_isasubr.cpcic_isa | pcic_isapnp | pcic_pci -# Databook TCIC/2 pcmcia/isa bridge -device tcic: pcmciabus -file dev/ic/tcic2.c tcic -attach tcic at isa with tcic_isa -file dev/isa/tcic2_isa.c tcic_isa - # # Machine-independent PCMCIA drivers # Index: dev/isa/files.isa === RCS file: /cvs/src/sys/dev/isa/f
Re: rename NCHNAMLEN
> Date: Tue, 26 Mar 2013 05:03:59 -0400
> From: Ted Unangst
>
> it's 2013. we don't have to pay extra for vowels.
Even in 2013, my terminals are still 80 columns wide. This makes some
of the lines wrap. Not really an improvement if you ask me.
> Index: nfs/nfs_vnops.c
> ===
> RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
> retrieving revision 1.140
> diff -u -p -r1.140 nfs_vnops.c
> --- nfs/nfs_vnops.c 17 Nov 2012 22:28:26 - 1.140
> +++ nfs/nfs_vnops.c 26 Mar 2013 08:59:30 -
> @@ -2455,7 +2456,7 @@ nfs_readdirplusrpc(struct vnode *vp, str
> info.nmi_md = mdsav2;
> dp->d_type = IFTODT(
> VTTOIF(np->n_vattr.va_type));
> - if (cnp->cn_namelen <= NCHNAMLEN) {
> + if (cnp->cn_namelen <=
> NAMECACHE_MAXLEN) {
> ndp->ni_vp = newvp;
> cache_purge(ndp->ni_dvp);
> nfs_cache_enter(ndp->ni_dvp,
> Index: kern/vfs_cache.c
> ===
> RCS file: /cvs/src/sys/kern/vfs_cache.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 vfs_cache.c
> --- kern/vfs_cache.c 4 Jan 2012 18:11:51 - 1.34
> +++ kern/vfs_cache.c 26 Mar 2013 08:59:59 -
> @@ -48,7 +48,7 @@
>
> /*
> * For simplicity (and economy of storage), names longer than
> - * a maximum length of NCHNAMLEN are not cached; they occur
> + * a maximum length of NAMECACHE_MAXLEN are not cached; they occur
> * infrequently in any case, and are almost never of interest.
> *
> * Upon reaching the last segment of a path, if the reference
> @@ -148,7 +148,7 @@ cache_lookup(struct vnode *dvp, struct v
> cnp->cn_flags &= ~MAKEENTRY;
> return (-1);
> }
> - if (cnp->cn_namelen > NCHNAMLEN) {
> + if (cnp->cn_namelen > NAMECACHE_MAXLEN) {
> nchstats.ncs_long++;
> cnp->cn_flags &= ~MAKEENTRY;
> return (-1);
> @@ -342,7 +342,7 @@ cache_enter(struct vnode *dvp, struct vn
> {
> struct namecache *ncp, *lncp;
>
> - if (!doingcache || cnp->cn_namelen > NCHNAMLEN)
> + if (!doingcache || cnp->cn_namelen > NAMECACHE_MAXLEN)
> return;
>
> /*
> Index: sys/namei.h
> ===
> RCS file: /cvs/src/sys/sys/namei.h,v
> retrieving revision 1.27
> diff -u -p -r1.27 namei.h
> --- sys/namei.h 30 Sep 2011 03:43:27 - 1.27
> +++ sys/namei.h 26 Mar 2013 08:58:58 -
> @@ -165,7 +165,7 @@ struct nameidata {
> * names looked up by namei.
> */
>
> -#define NCHNAMLEN 31 /* maximum name segment length we
> bother with */
> +#define NAMECACHE_MAXLEN31 /* maximum name segment length
> we bother with */
>
> struct namecache {
> TAILQ_ENTRY(namecache) nc_lru; /* Regular Entry LRU chain */
> @@ -177,7 +177,7 @@ structnamecache {
> struct vnode *nc_vp; /* vnode the name refers to */
> u_long nc_vpid;/* capability number of nc_vp */
> charnc_nlen;/* length of name */
> - charnc_name[NCHNAMLEN]; /* segment name */
> + charnc_name[NAMECACHE_MAXLEN]; /* segment name */
> };
>
> #ifdef _KERNEL
>
>
rename NCHNAMLEN
it's 2013. we don't have to pay extra for vowels.
Index: nfs/nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs/nfs_vnops.c 17 Nov 2012 22:28:26 - 1.140
+++ nfs/nfs_vnops.c 26 Mar 2013 08:59:30 -
@@ -2455,7 +2456,7 @@ nfs_readdirplusrpc(struct vnode *vp, str
info.nmi_md = mdsav2;
dp->d_type = IFTODT(
VTTOIF(np->n_vattr.va_type));
- if (cnp->cn_namelen <= NCHNAMLEN) {
+ if (cnp->cn_namelen <=
NAMECACHE_MAXLEN) {
ndp->ni_vp = newvp;
cache_purge(ndp->ni_dvp);
nfs_cache_enter(ndp->ni_dvp,
Index: kern/vfs_cache.c
===
RCS file: /cvs/src/sys/kern/vfs_cache.c,v
retrieving revision 1.34
diff -u -p -r1.34 vfs_cache.c
--- kern/vfs_cache.c4 Jan 2012 18:11:51 - 1.34
+++ kern/vfs_cache.c26 Mar 2013 08:59:59 -
@@ -48,7 +48,7 @@
/*
* For simplicity (and economy of storage), names longer than
- * a maximum length of NCHNAMLEN are not cached; they occur
+ * a maximum length of NAMECACHE_MAXLEN are not cached; they occur
* infrequently in any case, and are almost never of interest.
*
* Upon reaching the last segment of a path, if the reference
@@ -148,7 +148,7 @@ cache_lookup(struct vnode *dvp, struct v
cnp->cn_flags &= ~MAKEENTRY;
return (-1);
}
- if (cnp->cn_namelen > NCHNAMLEN) {
+ if (cnp->cn_namelen > NAMECACHE_MAXLEN) {
nchstats.ncs_long++;
cnp->cn_flags &= ~MAKEENTRY;
return (-1);
@@ -342,7 +342,7 @@ cache_enter(struct vnode *dvp, struct vn
{
struct namecache *ncp, *lncp;
- if (!doingcache || cnp->cn_namelen > NCHNAMLEN)
+ if (!doingcache || cnp->cn_namelen > NAMECACHE_MAXLEN)
return;
/*
Index: sys/namei.h
===
RCS file: /cvs/src/sys/sys/namei.h,v
retrieving revision 1.27
diff -u -p -r1.27 namei.h
--- sys/namei.h 30 Sep 2011 03:43:27 - 1.27
+++ sys/namei.h 26 Mar 2013 08:58:58 -
@@ -165,7 +165,7 @@ struct nameidata {
* names looked up by namei.
*/
-#defineNCHNAMLEN 31 /* maximum name segment length we
bother with */
+#defineNAMECACHE_MAXLEN31 /* maximum name segment length
we bother with */
struct namecache {
TAILQ_ENTRY(namecache) nc_lru; /* Regular Entry LRU chain */
@@ -177,7 +177,7 @@ struct namecache {
struct vnode *nc_vp; /* vnode the name refers to */
u_long nc_vpid;/* capability number of nc_vp */
charnc_nlen;/* length of name */
- charnc_name[NCHNAMLEN]; /* segment name */
+ charnc_name[NAMECACHE_MAXLEN]; /* segment name */
};
#ifdef _KERNEL
mpls includes
the netmpls code includes various headers it doesn't really need. Index: mpls.h === RCS file: /cvs/src/sys/netmpls/mpls.h,v retrieving revision 1.25 diff -u -p -r1.25 mpls.h --- mpls.h 8 Sep 2010 08:00:56 - 1.25 +++ mpls.h 26 Mar 2013 08:05:43 - @@ -35,7 +35,6 @@ #include #include -#include #include #include Index: mpls_raw.c === RCS file: /cvs/src/sys/netmpls/mpls_raw.c,v retrieving revision 1.8 diff -u -p -r1.8 mpls_raw.c --- mpls_raw.c 3 Sep 2010 13:12:31 - 1.8 +++ mpls_raw.c 26 Mar 2013 08:05:21 - @@ -31,7 +31,6 @@ */ #include -#include #include #include #include @@ -39,12 +38,10 @@ #include #include #include -#include #include #include #include -#include #include Index: mpls_shim.c === RCS file: /cvs/src/sys/netmpls/mpls_shim.c,v retrieving revision 1.6 diff -u -p -r1.6 mpls_shim.c --- mpls_shim.c 28 Jan 2009 22:18:44 - 1.6 +++ mpls_shim.c 26 Mar 2013 08:03:49 - @@ -31,14 +31,12 @@ */ #include -#include #include #include #include #include #include -#include #include
uvm combine clearbits
uvm_pagefree calls atomic_clearbits_int too many times. Just
accumulate the flags we need to zap, then do it once.
Index: uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.122
diff -u -p -r1.122 uvm_page.c
--- uvm_page.c 12 Mar 2013 21:10:11 - 1.122
+++ uvm_page.c 26 Mar 2013 07:45:56 -
@@ -1053,6 +1053,7 @@ void
uvm_pagefree(struct vm_page *pg)
{
int saved_loan_count = pg->loan_count;
+ u_int flags_to_clear = 0;
#ifdef DEBUG
if (pg->uobject == (void *)0xdeadbeef &&
@@ -1115,7 +1116,7 @@ uvm_pagefree(struct vm_page *pg)
if (pg->pg_flags & PQ_ACTIVE) {
TAILQ_REMOVE(&uvm.page_active, pg, pageq);
- atomic_clearbits_int(&pg->pg_flags, PQ_ACTIVE);
+ flags_to_clear |= PQ_ACTIVE;
uvmexp.active--;
}
if (pg->pg_flags & PQ_INACTIVE) {
@@ -1123,7 +1124,7 @@ uvm_pagefree(struct vm_page *pg)
TAILQ_REMOVE(&uvm.page_inactive_swp, pg, pageq);
else
TAILQ_REMOVE(&uvm.page_inactive_obj, pg, pageq);
- atomic_clearbits_int(&pg->pg_flags, PQ_INACTIVE);
+ flags_to_clear |= PQ_INACTIVE;
uvmexp.inactive--;
}
@@ -1138,15 +1139,16 @@ uvm_pagefree(struct vm_page *pg)
if (pg->uanon) {
pg->uanon->an_page = NULL;
pg->uanon = NULL;
- atomic_clearbits_int(&pg->pg_flags, PQ_ANON);
+ flags_to_clear |= PQ_ANON;
}
/*
* Clean page state bits.
*/
- atomic_clearbits_int(&pg->pg_flags, PQ_AOBJ); /* XXX: find culprit */
- atomic_clearbits_int(&pg->pg_flags, PQ_ENCRYPT|
- PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|PG_CLEAN|PG_CLEANCHK);
+ flags_to_clear |= PQ_AOBJ; /* XXX: find culprit */
+ flags_to_clear |= PQ_ENCRYPT|PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|
+ PG_CLEAN|PG_CLEANCHK;
+ atomic_clearbits_int(&pg->pg_flags, flags_to_clear);
/*
* and put on free queue
max crypto
There's a rather futile check for wrap around in crypto.c. The problem
is, if the number of crypto devs is anywhere near wrapping, the
malloc call a few lines below has long since exploded.
Just define a static max count and don't go over it.
Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.59
diff -u -p -r1.59 crypto.c
--- crypto.c11 Jan 2011 15:42:05 - 1.59
+++ crypto.c26 Mar 2013 07:35:33 -
@@ -245,8 +245,7 @@ crypto_get_driverid(u_int8_t flags)
/* Out of entries, allocate some more. */
if (i == crypto_drivers_num) {
- /* Be careful about wrap-around. */
- if (2 * crypto_drivers_num <= crypto_drivers_num) {
+ if (crypto_drivers_num >= CRYPTO_DRIVERS_MAX) {
splx(s);
return -1;
}
Index: cryptodev.h
===
RCS file: /cvs/src/sys/crypto/cryptodev.h,v
retrieving revision 1.56
diff -u -p -r1.56 cryptodev.h
--- cryptodev.h 29 Jun 2012 14:48:04 - 1.56
+++ cryptodev.h 26 Mar 2013 07:35:54 -
@@ -57,6 +57,7 @@
/* Some initial values */
#define CRYPTO_DRIVERS_INITIAL 4
+#define CRYPTO_DRIVERS_MAX 128
#define CRYPTO_SW_SESSIONS 32
/* HMAC values */
nfs pathconf
After an absence of 9 years, I make my triumphant return to sys/nfs.
There are some silly programs out there (looking at you boost) that
actually use pathconf instead of just hard coding 1024 for max path
length. If you run them from nfs, fireworks ensue.
Here's a pathconf implementation for nfs, copied mostly from ufs. Even
if some of these values are lies, they're better than nothing. My
theory is that the values you care about (NAME_MAX, PATH_MAX) are
going to be right, and the values you don't (REC_MAX_XFER_SIZE) are
harmless even if incorrect.
Index: nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs_vnops.c 17 Nov 2012 22:28:26 - 1.140
+++ nfs_vnops.c 26 Mar 2013 07:04:53 -
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
@@ -2937,19 +2938,70 @@ loop:
/*
* Return POSIX pathconf information applicable to nfs.
- *
- * The NFS V2 protocol doesn't support this, so just return EINVAL
- * for V2.
*/
/* ARGSUSED */
int
nfs_pathconf(void *v)
{
-#if 0
struct vop_pathconf_args *ap = v;
-#endif
+ struct nfsmount *nmp = VFSTONFS(ap->a_vp->v_mount);
+ int error = 0;
- return (EINVAL);
+ switch (ap->a_name) {
+ case _PC_LINK_MAX:
+ *ap->a_retval = LINK_MAX;
+ break;
+ case _PC_NAME_MAX:
+ *ap->a_retval = NAME_MAX;
+ break;
+ case _PC_PATH_MAX:
+ *ap->a_retval = PATH_MAX;
+ break;
+ case _PC_PIPE_BUF:
+ *ap->a_retval = PIPE_BUF;
+ break;
+ case _PC_CHOWN_RESTRICTED:
+ *ap->a_retval = 1;
+ break;
+ case _PC_NO_TRUNC:
+ *ap->a_retval = 1;
+ break;
+ case _PC_PRIO_IO:
+ *ap->a_retval = 0;
+ break;
+ case _PC_SYNC_IO:
+ *ap->a_retval = 0;
+ break;
+ case _PC_ALLOC_SIZE_MIN:
+ *ap->a_retval = NFS_FABLKSIZE;
+ break;
+ case _PC_FILESIZEBITS:
+ *ap->a_retval = 64;
+ break;
+ case _PC_REC_INCR_XFER_SIZE:
+ *ap->a_retval = min(nmp->nm_rsize, nmp->nm_wsize);
+ break;
+ case _PC_REC_MAX_XFER_SIZE:
+ *ap->a_retval = -1; /* means ``unlimited'' */
+ break;
+ case _PC_REC_MIN_XFER_SIZE:
+ *ap->a_retval = min(nmp->nm_rsize, nmp->nm_wsize);
+ break;
+ case _PC_REC_XFER_ALIGN:
+ *ap->a_retval = PAGE_SIZE;
+ break;
+ case _PC_SYMLINK_MAX:
+ *ap->a_retval = MAXPATHLEN;
+ break;
+ case _PC_2_SYMLINKS:
+ *ap->a_retval = 1;
+ break;
+ default:
+ error = EINVAL;
+ break;
+ }
+
+ return (error);
}
/*
