diff to add posix_madvise().
Here is a diff to add posix_madvise() to libc. Mostly from NetBSD. Index: sys/sys/mman.h === RCS file: /cvs/src/sys/sys/mman.h,v retrieving revision 1.18 diff -u -p -r1.18 mman.h --- sys/sys/mman.h 21 Jul 2003 22:52:19 - 1.18 +++ sys/sys/mman.h 20 Apr 2010 00:56:28 - @@ -72,15 +72,26 @@ #defineMAP_FLAGMASK0x17f7 /* - * Advice to madvise + * POSIX memory advisory values. + * Note: keep consistent with the original defintions below. */ -#defineMADV_NORMAL 0 /* no further special treatment */ -#defineMADV_RANDOM 1 /* expect random page references */ -#defineMADV_SEQUENTIAL 2 /* expect sequential page references */ -#defineMADV_WILLNEED 3 /* will need these pages */ -#defineMADV_DONTNEED 4 /* dont need these pages */ -#defineMADV_SPACEAVAIL 5 /* insure that resources are reserved */ -#defineMADV_FREE 6 /* pages are empty, free them */ +#definePOSIX_MADV_NORMAL 0 /* no further special treatment */ +#definePOSIX_MADV_RANDOM 1 /* expect random page references */ +#definePOSIX_MADV_SEQUENTIAL 2 /* expect sequential page references */ +#definePOSIX_MADV_WILLNEED 3 /* will need these pages */ +#definePOSIX_MADV_DONTNEED 4 /* don't need these pages */ + +/* + * Original advice values, equivalent to POSIX defintions, + * and few implementation-specific ones. + */ +#defineMADV_NORMAL POSIX_MADV_NORMAL +#defineMADV_RANDOM POSIX_MADV_RANDOM +#defineMADV_SEQUENTIAL POSIX_MADV_SEQUENTIAL +#defineMADV_WILLNEED POSIX_MADV_WILLNEED +#defineMADV_DONTNEED POSIX_MADV_DONTNEED +#defineMADV_SPACEAVAIL 5 /* insure that resources are reserved */ +#defineMADV_FREE 6 /* pages are empty, free them */ /* * Flags to minherit @@ -122,6 +133,7 @@ int madvise(void *, size_t, int); intmincore(void *, size_t, char *); intminherit(void *, size_t, int); void * mquery(void *, size_t, int, int, int, off_t); +intposix_madvise(void *, size_t, int); __END_DECLS #endif /* !_KERNEL */ Index: lib/libc/shlib_version === RCS file: /cvs/src/lib/libc/shlib_version,v retrieving revision 1.121 diff -u -p -r1.121 shlib_version @@ -1,4 +1,4 @@ major=53 -minor=1 +minor=2 # note: If changes were made to include/thread_private.h or if system # calls were added/changed then libpthread must also be updated. Index: lib/libc/sys/Makefile.inc === RCS file: /cvs/src/lib/libc/sys/Makefile.inc,v retrieving revision 1.89 diff -u -p -r1.89 Makefile.inc --- lib/libc/sys/Makefile.inc 3 Feb 2010 20:49:00 - 1.89 +++ lib/libc/sys/Makefile.inc 20 Apr 2010 00:35:43 - @@ -23,6 +23,9 @@ DPSRCS+= Lint_Ovfork.c Lint_brk.c Lint_e Lint_setjmp.c Lint_longjmp.c \ Lint_sigsetjmp.c Lint_siglongjmp.c +# glue to offer userland wrappers for some syscalls +SRCS+= posix_madvise.c + # glue to provide compatibility between GCC 1.X and 2.X and for compat # with old syscall interfaces. SRCS+= ftruncate.c lseek.c mquery.c mmap.c ptrace.c semctl.c truncate.c \ @@ -264,6 +267,7 @@ MLINKS+=gettimeofday.2 settimeofday.2 MLINKS+=getuid.2 geteuid.2 MLINKS+=kqueue.2 kevent.2 kqueue.2 EV_SET.2 MLINKS+=intro.2 errno.2 +MLINKS+=madvise.2 posix_madvise.2 MLINKS+=mlock.2 munlock.2 MLINKS+=mlockall.2 munlockall.2 MLINKS+=mount.2 unmount.2 Index: lib/libc/sys/madvise.2 === RCS file: /cvs/src/lib/libc/sys/madvise.2,v retrieving revision 1.14 diff -u -p -r1.14 madvise.2 --- lib/libc/sys/madvise.2 31 May 2007 19:19:32 - 1.14 +++ lib/libc/sys/madvise.2 20 Apr 2010 01:25:30 - @@ -30,23 +30,30 @@ .\" .\"@(#)madvise.2 8.1 (Berkeley) 6/9/93 .\" -.Dd $Mdocdate: May 31 2007 $ +.Dd $Mdocdate$ .Dt MADVISE 2 .Os .Sh NAME -.Nm madvise +.Nm madvise , +.Nm posix_madvise .Nd give advice about use of memory .Sh SYNOPSIS .Fd #include .Fd #include .Ft int .Fn madvise "void *addr" "size_t len" "int behav" +.Ft int +.Fn posix_madvise "void *addr" "size_t len" "int behav" .Sh DESCRIPTION The .Fn madvise system call allows a process that has knowledge of its memory behavior to describe it to the system. +The +.Fn posix_madvise +interface is identical and is provided for standards conformance. +.Pp The possible behaviors are: .Bl -tag -width MADV_SEQUENTIAL .It Dv MADV_NORMAL @@ -64,6 +71,15 @@ Ensure that resources are reserved. .It Dv MADV_FREE The pages don't contain any useful data and can be recycled. .El +.Pp +Portable programs that call the +.Fn posix_madvise +inte
Re: Completing softraid support (sparc/sparc64 ramdisk)
It really is very simple -- If you get it (a) build and then tested (b) then tell me what the growth to the media is then it can be commited. I am the custodian of the extremely size-sensitive install media... > if we are dropping bioctl then we might as well drop CRYPTO. You really > one with the other. > > On Mon, Apr 19, 2010 at 09:05:43PM +0200, David Coppa wrote: > > On Mon, Apr 19, 2010 at 8:57 PM, Mark Kettenis > > wrote: > > >> Date: Mon, 19 Apr 2010 07:05:53 +0200 > > >> From: David Coppa > > >> > > >> Hi, > > >> This diff adds missing bits for softraid support into sparc/sparc64 > > >> ramdisks. > > >> > > >> Tested on my Blade 150, bsd.rd didn't overflow. > > >> > > >> Comments? OKs? > > > > > > For sparc64, I think we shouldn't add bioctl this to ramdisk/list and > > > ramdiskB/list. These are floppy images and space is a bit tight. > > > Besides, you didn't add CRYPTO to RAMDISKU1 and RAMDISKU5, so it > > > wouldn't be terribly useful anyway. > > > > I'll remove sbin/bioctl from ramdisk/list and ramdiskB/list > > > > > And you'll need to test the sparc bits (or drop them). > > > > Cannot test since i don't have a sparc machine available: so I'll drop > > these too. > > > > ok?
Re: Completing softraid support (sparc/sparc64 ramdisk)
if we are dropping bioctl then we might as well drop CRYPTO. You really one with the other. On Mon, Apr 19, 2010 at 09:05:43PM +0200, David Coppa wrote: > On Mon, Apr 19, 2010 at 8:57 PM, Mark Kettenis > wrote: > >> Date: Mon, 19 Apr 2010 07:05:53 +0200 > >> From: David Coppa > >> > >> Hi, > >> This diff adds missing bits for softraid support into sparc/sparc64 > >> ramdisks. > >> > >> Tested on my Blade 150, bsd.rd didn't overflow. > >> > >> Comments? OKs? > > > > For sparc64, I think we shouldn't add bioctl this to ramdisk/list and > > ramdiskB/list. These are floppy images and space is a bit tight. > > Besides, you didn't add CRYPTO to RAMDISKU1 and RAMDISKU5, so it > > wouldn't be terribly useful anyway. > > I'll remove sbin/bioctl from ramdisk/list and ramdiskB/list > > > And you'll need to test the sparc bits (or drop them). > > Cannot test since i don't have a sparc machine available: so I'll drop > these too. > > ok?
Još samo 7 dana za spremanje uz popust i poklon!
ProleDno spremanje - još 7 dana sa popustom! Odaberite bilo koja 2 ili više proizvoda iz ponude ProleDno spremanje i osvojite 10% POPUSTA i POKLON Mini kuhinjsku vagu! PoE>urite, napravite svoj paket još danas i oD istite svoj dom uz minimum napora i za upola kraDe vreme! Neki od proizvoda iz ponude za veliko spremanje Omni Floor Polisher Space Bag Cube Shamwow - magiD ne krpe Omni Floor Polisher Space Bag Cube Shamwow ProleDno spremanje Kliknite ovde i napravite svoj paket odmah! ProleDno spremanje Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u našoj poklon igri ili nagradnom kvizu ili se prijavili za e-D asopis Top Shop-a ili nekog od nasih brendova. Ponude date u ovom e-mailu vaE>e iskljuD ivo za porudE>bine upuDene putem Interneta ili broja telefona 021 489 26 60. Ukoliko ne E>elite više da primate naše elektronske poruke, za odjavljivanje sa naše e-mailing liste, kliknite ovde. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@news.top-shop.rs [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
Re: network interface renaming diff
* Claudio Jeker [2010-04-19 18:40]: > On Mon, Apr 19, 2010 at 04:35:31PM +0200, Henning Brauer wrote: > > * Gregory Edigarov [2010-04-19 14:36]: > > > On Mon, 19 Apr 2010 14:18:02 +0200 > > > Henning Brauer wrote: > > > > > > > what problem does that solve? > > > > specifically, what problem does this solve that is not solved by > > > > interface groups? > > > sometimes it is better and necessary to have interfaces named under one > > > standartized name like fether0... fetherN for example > > > > ifconfig em0 group fether0 > > > > done > > > > Nice try but ifconfig will not allow that: > ifconfig: setifgroup: group names may not end in a digit how should I know, I just wrote the code ;( > I think there is a good reason we do not let groups be like interface > names. ack. but the basic concept still stands, use (probably single-member) groups as "aliases" for interfaces. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Completing softraid support (sparc/sparc64 ramdisk)
On Mon, Apr 19, 2010 at 8:57 PM, Mark Kettenis wrote: >> Date: Mon, 19 Apr 2010 07:05:53 +0200 >> From: David Coppa >> >> Hi, >> This diff adds missing bits for softraid support into sparc/sparc64 >> ramdisks. >> >> Tested on my Blade 150, bsd.rd didn't overflow. >> >> Comments? OKs? > > For sparc64, I think we shouldn't add bioctl this to ramdisk/list and > ramdiskB/list. These are floppy images and space is a bit tight. > Besides, you didn't add CRYPTO to RAMDISKU1 and RAMDISKU5, so it > wouldn't be terribly useful anyway. I'll remove sbin/bioctl from ramdisk/list and ramdiskB/list > And you'll need to test the sparc bits (or drop them). Cannot test since i don't have a sparc machine available: so I'll drop these too. ok?
Re: Completing softraid support (sparc/sparc64 ramdisk)
> Date: Mon, 19 Apr 2010 07:05:53 +0200
> From: David Coppa
>
> Hi,
> This diff adds missing bits for softraid support into sparc/sparc64
> ramdisks.
>
> Tested on my Blade 150, bsd.rd didn't overflow.
>
> Comments? OKs?
For sparc64, I think we shouldn't add bioctl this to ramdisk/list and
ramdiskB/list. These are floppy images and space is a bit tight.
Besides, you didn't add CRYPTO to RAMDISKU1 and RAMDISKU5, so it
wouldn't be terribly useful anyway.
And you'll need to test the sparc bits (or drop them).
> Index: distrib/sparc64/bsd.rd/list
> ===
> RCS file: /cvs/src/distrib/sparc64/bsd.rd/list,v
> retrieving revision 1.35
> diff -N -u -p distrib/sparc64/bsd.rd/list
> --- distrib/sparc64/bsd.rd/list 4 Apr 2010 18:35:51 - 1.35
> +++ distrib/sparc64/bsd.rd/list 19 Apr 2010 06:42:08 -
> @@ -55,6 +55,7 @@ LINKinstbin
> usr/bin/gzip usr/bin/gunzip usr/bin/g
> LINK instbin usr/bin/less usr/bin/more
> LINK instbin usr/bin/sed
> LINK instbin sbin/sysctl
> +LINK instbin sbin/bioctl
>
> SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
> SPECIAL cd dev; sh MAKEDEV ramdisk
> Index: distrib/sparc64/ramdisk/list
> ===
> RCS file: /cvs/src/distrib/sparc64/ramdisk/list,v
> retrieving revision 1.33
> diff -N -u -p distrib/sparc64/ramdisk/list
> --- distrib/sparc64/ramdisk/list 31 Mar 2010 17:51:42 - 1.33
> +++ distrib/sparc64/ramdisk/list 19 Apr 2010 06:42:08 -
> @@ -50,6 +50,7 @@ LINKinstbin
> usr/bin/gzip usr/bin/gunzip usr/bin/g
> LINK instbin usr/bin/less usr/bin/more
> LINK instbin usr/bin/sed
> LINK instbin sbin/sysctl
> +LINK instbin sbin/bioctl
>
> SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
> SPECIAL cd dev; sh MAKEDEV ramdisk
> Index: distrib/sparc64/ramdiskB/list
> ===
> RCS file: /cvs/src/distrib/sparc64/ramdiskB/list,v
> retrieving revision 1.27
> diff -N -u -p distrib/sparc64/ramdiskB/list
> --- distrib/sparc64/ramdiskB/list 31 Mar 2010 17:51:42 - 1.27
> +++ distrib/sparc64/ramdiskB/list 19 Apr 2010 06:42:08 -
> @@ -48,6 +48,7 @@ LINKinstbin
> usr/bin/gzip usr/bin/gunzip usr/bin/g
> LINK instbin usr/bin/less usr/bin/more
> LINK instbin usr/bin/sed
> LINK instbin sbin/sysctl
> +LINK instbin sbin/bioctl
>
> SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
> SPECIAL cd dev; sh MAKEDEV ramdisk
> Index: sys/arch/sparc/conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/sparc/conf/RAMDISK,v
> retrieving revision 1.66
> diff -N -u -p sys/arch/sparc/conf/RAMDISK
> --- sys/arch/sparc/conf/RAMDISK 28 Jul 2009 12:47:34 - 1.66
> +++ sys/arch/sparc/conf/RAMDISK 19 Apr 2010 06:43:21 -
> @@ -24,6 +24,7 @@ option CD9660 # ISO 9660 + Rock Ridge
> file system
> option INET# IP + ICMP + TCP + UDP
> #option INET6 # IPv6 (needs INET)
> option BOOT_CONFIG # add support for boot -c
> +option CRYPTO # Cryptographic framework
>
> # Options for variants of the Sun SPARC architecture.
> # At least one is required.
> Index: sys/arch/sparc64/conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/sparc64/conf/RAMDISK,v
> retrieving revision 1.97
> diff -N -u -p sys/arch/sparc64/conf/RAMDISK
> --- sys/arch/sparc64/conf/RAMDISK 3 Apr 2010 00:53:30 - 1.97
> +++ sys/arch/sparc64/conf/RAMDISK 19 Apr 2010 06:43:22 -
> @@ -30,6 +30,7 @@ option UDF # UDF (DVD) file system
> option INET# IP + ICMP + TCP + UDP
> option INET6 # IPv6 (needs INET)
> option BOOT_CONFIG # add support for boot -c
> +option CRYPTO # Cryptographic framework
>
> option WSEMUL_SUN # provide sun terminal emulation;
> required
> option WSEMUL_NO_VT100 # do not provide vt100 terminal
> emulation
Re: Source Overview
On Mon, 19 Apr 2010 16:57:38 +0200 "Bret S. Lambert"
wrote:
> src/sys/
> kern/ <- generic stuffs (signals, scheduling, vnodes,
> syscalls) net/<- generic net stuffs (interface handling, pf,
> routing) netinet{,6}/ <- IPv{4,6} stuffs
> net*/ <- non-IP network stuffs
> sys/<- system header files
> arch/ <- architecture-dependant code
> dev/<- hardware drivers stuffs
> crypto/ <- kernel crypto stuffs
> *fs/<- filesystem code
> nfs/<- the source of all horror
> conf/ <- kernel configuration stuffs
> lib/<- libc routines ported to the kernel, mostly
> scsi/ <- self-explanatory
> uvm/<- virtual memory stuffs
> altq/ <- also self-explanatory
> compat/ <- compatibility routines for other OSes
> ddb/<- kernel debugger stuffs
>
> I may have missed something (or be slightly incorrect; hopefully
> someone smarter than me can help clean this up if I'm too far off).
Also, `man hier` can be real helpful as a general reference.
--
The OpenBSD Journal - http://www.undeadly.org
Re: network interface renaming diff
On Mon, Apr 19, 2010 at 04:35:31PM +0200, Henning Brauer wrote: > * Gregory Edigarov [2010-04-19 14:36]: > > On Mon, 19 Apr 2010 14:18:02 +0200 > > Henning Brauer wrote: > > > > > what problem does that solve? > > > specifically, what problem does this solve that is not solved by > > > interface groups? > > sometimes it is better and necessary to have interfaces named under one > > standartized name like fether0... fetherN for example > > ifconfig em0 group fether0 > > done > Nice try but ifconfig will not allow that: ifconfig: setifgroup: group names may not end in a digit I think there is a good reason we do not let groups be like interface names. -- :wq Claudio
Re: Source Overview
On Mon, Apr 19, 2010 at 8:48 AM, Adam M. Dutko wrote: > 1) Are there areas that are easier for "relative newbies" to start in versus > other areas? I know this depends on a lot of things, to include experience. > Hypothetically, someone that has some C experience, but not a lot of kernel > (and subsystem) experience. Is it better to start from the bottom up like > bootstrap to init? or is it better to start with memory management? network > drivers? What is usually the best area from a learning and future utility > perspective? Start with something you're interested in, use, and can test. If you write code that you don't use, it'll be incomplete and unreliable. If you work on something you're not interested in, it'll suffer from your ennui. If you can't test it, it'll be crap. Once you get into it, the interrelations in the code will suck you into other parts. Philip Guenther
Re: Source Overview
> And if you value your sanity, stay out of anything resembling filesystems. This is a lie. Hacking on filesystems, and the VFS layer in general is a very rewarding experince, just ask Bob. NFS for example, has been a source of joy for OpenBSD developers for years! >> 2) Is there something like an "openbsd janitors" project where newbies can >> start contributing small patches? similar to the Linux janitors project? > > Not at all. The philosophy behind not having one is that it's considered dangerous > to farm out work to the inexperienced (and this exact topic has been brought up > before, usually by people whining that we didn't make them feel special enough > by not having one). Also it leads to people doing "KNF" style diffs, just to do KNF style diffs. Noone learns anything. Most "KNF" style diffs you see coming from developers is due to them having to read some code, and they cleaned up a little while doing so. While KNF is great, doing KNF just for the sake of doing KNF is hardly ever worth it IMHO.
Re: Source Overview
On Mon, Apr 19, 2010 at 11:48:02AM -0400, Adam M. Dutko wrote: > On Mon, Apr 19, 2010 at 10:57 AM, Bret S. Lambert wrote: > > > > > ... ... > > > > Hopefully this is useful for somebody. > > > > It is, thank you. > > With regard to the other questions I peppered everyone with... :-) > > 1) Are there areas that are easier for "relative newbies" to start in versus > other areas? I know this depends on a lot of things, to include experience. > Hypothetically, someone that has some C experience, but not a lot of kernel > (and subsystem) experience. Is it better to start from the bottom up like > bootstrap to init? or is it better to start with memory management? network > drivers? What is usually the best area from a learning and future utility > perspective? Only you can determine that so pick an area you are interested in and simply start hacking on it. > > 2) Is there something like an "openbsd janitors" project where newbies can > start contributing small patches? similar to the Linux janitors project? Janitor is actually a very hard task that requires in-depth knowledge of many sub-systems and is therefore not a good n00b starting point. > > Thanks again.
Re: Source Overview
On Monday, April 19, "Adam M. Dutko" wrote: > > 1) Are there areas that are easier for "relative newbies" to start in versus > other areas? I know this depends on a lot of things, to include experience. > Hypothetically, someone that has some C experience, but not a lot of kernel > (and subsystem) experience. Is it better to start from the bottom up like > bootstrap to init? or is it better to start with memory management? network > drivers? What is usually the best area from a learning and future utility > perspective? Many a kernel hacker was suckered into the fold by writing a network driver. In general, drivers are fairly "easy", in that there are lots to copy from, and they tend to be fairly self-contained. > 2) Is there something like an "openbsd janitors" project where newbies can > start contributing small patches? similar to the Linux janitors project? Well, there is the bug database. In general, people pick what they don't like, or otherwise causes them to itch in uncomfortable places, and they then scratch that itch until... well, you know, they're satisfied. :) Seriously, pick something, and start in. If it's too much, move to another area. Don't get discouraged, just keep trying. --Toby.
Re: Source Overview
On Mon, Apr 19, 2010 at 11:48:02AM -0400, Adam M. Dutko wrote: > On Mon, Apr 19, 2010 at 10:57 AM, Bret S. Lambert wrote: > > > > > ... ... > > > > Hopefully this is useful for somebody. > > > > It is, thank you. > > With regard to the other questions I peppered everyone with... :-) > > 1) Are there areas that are easier for "relative newbies" to start in versus > other areas? I know this depends on a lot of things, to include experience. > Hypothetically, someone that has some C experience, but not a lot of kernel > (and subsystem) experience. Is it better to start from the bottom up like > bootstrap to init? or is it better to start with memory management? network > drivers? What is usually the best area from a learning and future utility > perspective? If you're going after userland stuff, the advice I've given (and where I started) is to read libc; it's the basis of userland programming, and illustrates some of the tricks you can do with C. For the kernel side, I'd say start looking at the system calls (cd /usr/src/sys/kern && grep -n ^sys_ *.c). Everything else is just going deeper into the rabbit hole. And if you value your sanity, stay out of anything resembling filesystems. > > 2) Is there something like an "openbsd janitors" project where newbies can > start contributing small patches? similar to the Linux janitors project? Not at all. The philosophy behind not having one is that it's considered dangerous to farm out work to the inexperienced (and this exact topic has been brought up before, usually by people whining that we didn't make them feel special enough by not having one). Read, understand, find an issue, post a patch, get told why it's wrong, fix it, repeat. - Bert
Re: network interface renaming diff
> Neat idea, but you do no sanity checking at all. So you could end up with > two interfaces with the same name (very bad) or an interface with a name > that violates the naming scheme. > Since if_xname is used in various places to identify interfaces changing > their name is dangerous. e.g. pf and the routing daemons use interface > names in the config. So it is important to do at least a bit of sanity > checking. You will find me also not supporting interface renaming. There are just too many subsystems that would need a hook, to cope with such behaviour.
Re: Source Overview
On Mon, Apr 19, 2010 at 10:57 AM, Bret S. Lambert wrote: > > ... ... > Hopefully this is useful for somebody. > It is, thank you. With regard to the other questions I peppered everyone with... :-) 1) Are there areas that are easier for "relative newbies" to start in versus other areas? I know this depends on a lot of things, to include experience. Hypothetically, someone that has some C experience, but not a lot of kernel (and subsystem) experience. Is it better to start from the bottom up like bootstrap to init? or is it better to start with memory management? network drivers? What is usually the best area from a learning and future utility perspective? 2) Is there something like an "openbsd janitors" project where newbies can start contributing small patches? similar to the Linux janitors project? Thanks again.
Re: Source Overview
On Mon, Apr 19, 2010 at 09:59:06AM -0400, Adam M. Dutko wrote:
> The obvious answer to this questions is "Just read the source..." but I
> still want to ask if someone is aware of a good overview of the OpenBSD
> source code? I've watched several presentations by Ted Unangst, Jason Dixon
> and co. and there seems to be a good amount of information spread across the
> web, but not a single canonical reference besides the source code (yes, I
> know source is very important).
>
> I know the base of code is very very large, so maybe instead of the whole
> repository, how about important parts/subsystems? Are any of you aware of
> such a document or documents? Are there areas that are easier for "relative
> newbies" to start in versus other areas? (eg. wireless drivers vs. SMP) Is
> there something like an "openbsd janitors" project where newbies can start?
> Thanks in advance.
http://www.openbsd.org/papers/
has some good pointers; specifically claudio@'s presentations on the network
internals which have call graphs, and jsg@'s introduction to drivers.
man 9 style is a good introduction to the conventions used in the source tree.
I'm going to assume that you mean an overview as to which directories mean
what inside the kernel, since outside of the kernel, it's rather self-evident
(e.g., src/usr.sbin/foo is for /usr/sbin/foo):
src/sys/
kern/ <- generic stuffs (signals, scheduling, vnodes, syscalls)
net/<- generic net stuffs (interface handling, pf, routing)
netinet{,6}/<- IPv{4,6} stuffs
net*/ <- non-IP network stuffs
sys/<- system header files
arch/ <- architecture-dependant code
dev/<- hardware drivers stuffs
crypto/ <- kernel crypto stuffs
*fs/<- filesystem code
nfs/<- the source of all horror
conf/ <- kernel configuration stuffs
lib/<- libc routines ported to the kernel, mostly
scsi/ <- self-explanatory
uvm/<- virtual memory stuffs
altq/ <- also self-explanatory
compat/ <- compatibility routines for other OSes
ddb/<- kernel debugger stuffs
I may have missed something (or be slightly incorrect; hopefully
someone smarter than me can help clean this up if I'm too far off).
Hopefully this is useful for somebody.
>
> -Adam
Re: network interface renaming diff
* Gregory Edigarov [2010-04-19 14:56]: > On Mon, 19 Apr 2010 08:34:12 -0400 > Simon Perreault wrote: > > > On 2010-04-19 08:31, Gregory Edigarov wrote: > > > sometimes it is better and necessary to have interfaces named under > > > one standartized name like fether0... fetherN for example > > > > Why? And how can groups not accomplish that? > > > > Simon > suppose you need to configure some interfaces of different makes: > em0, bge0, rl0, ath0 > to have name like: > ether0, ether1, ether2, ether3... > so you may plug in another card instead of ether2 for example. > without interface renaming you will end up rewriting the whole seciton > of your interface configuration script, while with it - you will only > have to change one line: > ifconfig bge0 name ether0 your what? mv hostname.em2 hostname.em3 is not black magic. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: network interface renaming diff
* Stuart Henderson [2010-04-19 14:53]: > On 2010/04/19 08:34, Simon Perreault wrote: > > On 2010-04-19 08:31, Gregory Edigarov wrote: > > >sometimes it is better and necessary to have interfaces named under one > > >standartized name like fether0... fetherN for example > > > > Why? And how can groups not accomplish that? > > There is one place I've found where groups aren't supported; > PF 'set skip on' has some special 'match the first letters of the > interface name' code rather than using interface groups. that is a bug. > The only place I've remotely wished for names other than our standard > schema is when using vlans (e.g. freebsd-style bge0.1700 creating a vlan > with tag 1700 on bge0), but not really wanted it badly enough to do > anything about it... same here actually :) -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: network interface renaming diff
* Gregory Edigarov [2010-04-19 14:36]: > On Mon, 19 Apr 2010 14:18:02 +0200 > Henning Brauer wrote: > > > what problem does that solve? > > specifically, what problem does this solve that is not solved by > > interface groups? > sometimes it is better and necessary to have interfaces named under one > standartized name like fether0... fetherN for example ifconfig em0 group fether0 done -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Source Overview
The obvious answer to this questions is "Just read the source..." but I still want to ask if someone is aware of a good overview of the OpenBSD source code? I've watched several presentations by Ted Unangst, Jason Dixon and co. and there seems to be a good amount of information spread across the web, but not a single canonical reference besides the source code (yes, I know source is very important). I know the base of code is very very large, so maybe instead of the whole repository, how about important parts/subsystems? Are any of you aware of such a document or documents? Are there areas that are easier for "relative newbies" to start in versus other areas? (eg. wireless drivers vs. SMP) Is there something like an "openbsd janitors" project where newbies can start? Thanks in advance. -Adam
Re: network interface renaming diff
On Mon, 19 Apr 2010 15:05:37 +0200 Claudio Jeker wrote: > On Mon, Apr 19, 2010 at 03:52:52PM +0300, Gregory Edigarov wrote: > > On Mon, 19 Apr 2010 08:34:12 -0400 > > Simon Perreault wrote: > > > > > On 2010-04-19 08:31, Gregory Edigarov wrote: > > > > sometimes it is better and necessary to have interfaces named > > > > under one standartized name like fether0... fetherN for example > > > > > > Why? And how can groups not accomplish that? > > > > > > Simon > > suppose you need to configure some interfaces of different makes: > > em0, bge0, rl0, ath0 > > to have name like: > > ether0, ether1, ether2, ether3... > > so you may plug in another card instead of ether2 for example. > > without interface renaming you will end up rewriting the whole > > seciton of your interface configuration script, while with it - you > > will only have to change one line: > > ifconfig bge0 name ether0 > > > > You can achive the same thing with interface groups. (Ok you can not > name them ether0 since a group may not end in a digit but the rest > works like a charm). there is one small thing one cannot do with interface groups: you cannot assign address to your interface. > We decided multiple times against renaming of interfaces since the > consequences introduced are normaly not fully understood. > Just overwriting if_xname is just the tip of the iceberg. Some > concerns were already mentioned in this thread. OK then. -- With best regards, Gregory Edigarov
Re: network interface renaming diff
On Mon, Apr 19, 2010 at 03:52:52PM +0300, Gregory Edigarov wrote: > On Mon, 19 Apr 2010 08:34:12 -0400 > Simon Perreault wrote: > > > On 2010-04-19 08:31, Gregory Edigarov wrote: > > > sometimes it is better and necessary to have interfaces named under > > > one standartized name like fether0... fetherN for example > > > > Why? And how can groups not accomplish that? > > > > Simon > suppose you need to configure some interfaces of different makes: > em0, bge0, rl0, ath0 > to have name like: > ether0, ether1, ether2, ether3... > so you may plug in another card instead of ether2 for example. > without interface renaming you will end up rewriting the whole seciton > of your interface configuration script, while with it - you will only > have to change one line: > ifconfig bge0 name ether0 > You can achive the same thing with interface groups. (Ok you can not name them ether0 since a group may not end in a digit but the rest works like a charm). We decided multiple times against renaming of interfaces since the consequences introduced are normaly not fully understood. Just overwriting if_xname is just the tip of the iceberg. Some concerns were already mentioned in this thread. -- :wq Claudio
Re: network interface renaming diff
On Mon, 19 Apr 2010 08:34:12 -0400 Simon Perreault wrote: > On 2010-04-19 08:31, Gregory Edigarov wrote: > > sometimes it is better and necessary to have interfaces named under > > one standartized name like fether0... fetherN for example > > Why? And how can groups not accomplish that? > > Simon suppose you need to configure some interfaces of different makes: em0, bge0, rl0, ath0 to have name like: ether0, ether1, ether2, ether3... so you may plug in another card instead of ether2 for example. without interface renaming you will end up rewriting the whole seciton of your interface configuration script, while with it - you will only have to change one line: ifconfig bge0 name ether0 -- With best regards, Gregory Edigarov
Re: network interface renaming diff
On 2010/04/19 08:34, Simon Perreault wrote: > On 2010-04-19 08:31, Gregory Edigarov wrote: > >sometimes it is better and necessary to have interfaces named under one > >standartized name like fether0... fetherN for example > > Why? And how can groups not accomplish that? There is one place I've found where groups aren't supported; PF 'set skip on' has some special 'match the first letters of the interface name' code rather than using interface groups. The only place I've remotely wished for names other than our standard schema is when using vlans (e.g. freebsd-style bge0.1700 creating a vlan with tag 1700 on bge0), but not really wanted it badly enough to do anything about it...
Re: network interface renaming diff
On Mon, 19 Apr 2010 14:17:59 +0200
Alexander Hall wrote:
> On 04/19/10 13:34, Gregory Edigarov wrote:
> > Hello,
> >
> > This diff adds possibility for the network interfaces to have an
> > arbitrary names. this is done via ifconfig name
>
> Just curious... What is the purpose?
>
> For pf.conf you can add an interface group name to the interface and
> use that as an alias.
well, it is not much for pf...
it is for the situations when it is better to have interface named in
one single strandard like ether0 ... etherN and not by their
make/model/driver. i had such situation some time before.
>
> /Alexander
>
>
> > Please test.
> > Thank you.
> >
> >
> > --- /usr/src/sys/net/if.c.orig Sat Apr 17 12:42:06 2010
> > +++ /usr/src/sys/net/if.c Sat Apr 17 13:27:12 2010
> > @@ -1416,6 +1416,17 @@
> > strlcpy(ifp->if_description, ifdescrbuf,
> > IFDESCRSIZE); }
> > break;
> > +
> > + case SIOCSIFNAME:
> > + if ((error = suser (p,0)) != 0)
> > + return (error);
> > + error = copyinstr(ifr->ifr_data, ifnamebuf,
> > + IFNAMSIZ,&bytesdone);
> > + if (error == 0) {
> > + (void)memset (ifp->if_xname, 0, IFNAMSIZ);
> > + strlcpy(ifp->if_xname,
> > ifnamebuf,IFNAMSIZ);
> > + }
> > + break;
> >
> > case SIOCGIFRTLABEL:
> > if (ifp->if_rtlabelid &&
> > --- /usr/src/sbin/ifconfig/ifconfig.c.orig Sat Apr 17
> > 13:43:47 2010 +++ /usr/src/sbin/ifconfig/ifconfig.c Sat Apr
> > 17 14:34:15 2010 @@ -149,6 +149,7 @@
> > void setifbroadaddr(const char *, int);
> > void setifdesc(const char *, int);
> > void unsetifdesc(const char *, int);
> > +void setifname(const char *, int);
> > void setifipdst(const char *, int);
> > void setifmetric(const char *, int);
> > void setifmtu(const char *, int);
> > @@ -465,6 +466,7 @@
> > { "descr", NEXTARG,0,
> > setifdesc }, { "-description", 1, 0,
> > unsetifdesc }, { "-descr", 1,
> > 0, unsetifdesc },
> > + { "name", 1, 0,
> > setifname}, { NULL, /*src*/ 0,
> > 0, setifaddr }, { NULL, /*dst*/
> > 0, 0, setifdstaddr },
> > { NULL, /*illegal*/0, 0, NULL }, @@
> > -1118,6 +1120,14 @@
> > /* ARGSUSED */
> > void
> > +setifname(const char *val, int ignored)
> > +{
> > + ifr.ifr_data = (caddr_t)val;
> > + if (ioctl(s, SIOCSIFNAME, &ifr) < 0)
> > + warn("SIOCSIFNAME");
> > +}
> > +/* ARGSUSED */
> > +void
> > setifipdst(const char *addr, int ignored)
> > {
> > in_getaddr(addr, DSTADDR);
> > --- /usr/include/sys/sockio.h.orig Sat Apr 17 14:33:11 2010
> > +++ /usr/include/sys/sockio.h Sat Apr 17 14:32:41 2010
> > @@ -179,6 +179,8 @@
> > #defineSIOCSLIFPHYRTABLEID _IOW('i', 161, struct ifreq) /*
> > set tunnel VRF id */ #defineSIOCGLIFPHYRTABLEID _IOWR('i',
> > 162, struct ifreq) /* get tunnel id */
> > +#define SIOCSIFNAME _IOW('i', 163, struct ifreq) /* set
> > interface name */ +
> > #defineSIOCSVH _IOWR('i', 245, struct
> > ifreq) /* set carp param */ #define
> > SIOCGVH _IOWR('i', 246, struct ifreq) /* get
> > carp param */
>
--
With best regards,
Gregory Edigarov
Re: network interface renaming diff
On 2010-04-19 08:31, Gregory Edigarov wrote: sometimes it is better and necessary to have interfaces named under one standartized name like fether0... fetherN for example Why? And how can groups not accomplish that? Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server--> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
Please test: TCP MSS vs PMTUD
PMTUD can only lower TCP MSS (either the default one or the one advertised by the peer), not raise it. This is how it was originally but it regressed at some point. The comments still mention the correct behaviour, but the code doesn't do what the comments say. This diff fixes that. Please test especially if you have unusual MTU, PMTUD, or MSS settings. Index: tcp_input.c === RCS file: /cvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.232 diff -u -r1.232 tcp_input.c --- tcp_input.c 11 Mar 2010 00:24:58 - 1.232 +++ tcp_input.c 15 Apr 2010 20:22:49 - @@ -3092,7 +3092,7 @@ * from maxseg, because now every segment carries options * and thus we normally have somewhat less data in segments. */ - tp->t_maxopd = mss; + tp->t_maxopd = offer == -1 ? min(mss, tp->t_maxopd) : mss; if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP && (tp->t_flags & TF_RCVD_TSTMP) == TF_RCVD_TSTMP) @@ -3122,7 +3122,7 @@ } else tp->snd_cwnd = mss; - tp->t_maxseg = mss; + tp->t_maxseg = offer == -1 ? min(mss, tp->t_maxseg) : mss; return (offer != -1 ? mssopt : mss); } -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server--> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
Re: network interface renaming diff
On Mon, 19 Apr 2010 14:18:02 +0200 Henning Brauer wrote: > what problem does that solve? > specifically, what problem does this solve that is not solved by > interface groups? sometimes it is better and necessary to have interfaces named under one standartized name like fether0... fetherN for example -- With best regards, Gregory Edigarov
Re: network interface renaming diff
On Mon, 19 Apr 2010 15:09:00 +0300 Gregory Edigarov wrote: > On Mon, 19 Apr 2010 13:52:13 +0200 > Claudio Jeker wrote: > > > On Mon, Apr 19, 2010 at 02:34:55PM +0300, Gregory Edigarov wrote: > > > Hello, > > > > > > This diff adds possibility for the network interfaces to have an > > > arbitrary names. this is done via ifconfig name > > > > > > > > > > Neat idea, but you do no sanity checking at all. So you could end up > > with two interfaces with the same name (very bad) or an interface > > with a name that violates the naming scheme. > > Since if_xname is used in various places to identify interfaces > > changing their name is dangerous. e.g. pf and the routing daemons > > use interface names in the config. So it is important to do at > > least a bit of sanity checking. > > No problem, wait for the second version then :-) Oh, just one question: could you be more specific about sanity tests i should implement. I could just think about duplicating names but may be you will tell... The whole idea come to my mind while i was strugling to move one of my dying cisco to openbsd. And on this temporary server I had 3 cards of different makes, so I thought renaming my interfaces so they will have some standartized names like fether0 ... fetherN would help me a bit. -- With best regards, Gregory Edigarov
Re: network interface renaming diff
On 04/19/10 13:34, Gregory Edigarov wrote:
> Hello,
>
> This diff adds possibility for the network interfaces to have an arbitrary
> names.
> this is done via ifconfig name
Just curious... What is the purpose?
For pf.conf you can add an interface group name to the interface and use
that as an alias.
/Alexander
> Please test.
> Thank you.
>
>
> --- /usr/src/sys/net/if.c.origSat Apr 17 12:42:06 2010
> +++ /usr/src/sys/net/if.c Sat Apr 17 13:27:12 2010
> @@ -1416,6 +1416,17 @@
> strlcpy(ifp->if_description, ifdescrbuf, IFDESCRSIZE);
> }
> break;
> +
> + case SIOCSIFNAME:
> + if ((error = suser (p,0)) != 0)
> + return (error);
> + error = copyinstr(ifr->ifr_data, ifnamebuf,
> + IFNAMSIZ,&bytesdone);
> + if (error == 0) {
> + (void)memset (ifp->if_xname, 0, IFNAMSIZ);
> + strlcpy(ifp->if_xname, ifnamebuf,IFNAMSIZ);
> + }
> + break;
>
> case SIOCGIFRTLABEL:
> if (ifp->if_rtlabelid &&
> --- /usr/src/sbin/ifconfig/ifconfig.c.origSat Apr 17 13:43:47 2010
> +++ /usr/src/sbin/ifconfig/ifconfig.c Sat Apr 17 14:34:15 2010
> @@ -149,6 +149,7 @@
> void setifbroadaddr(const char *, int);
> void setifdesc(const char *, int);
> void unsetifdesc(const char *, int);
> +void setifname(const char *, int);
> void setifipdst(const char *, int);
> void setifmetric(const char *, int);
> void setifmtu(const char *, int);
> @@ -465,6 +466,7 @@
> { "descr", NEXTARG,0, setifdesc },
> { "-description", 1,0, unsetifdesc },
> { "-descr", 1, 0, unsetifdesc },
> + { "name", 1, 0, setifname},
> { NULL, /*src*/ 0, 0, setifaddr },
> { NULL, /*dst*/ 0, 0, setifdstaddr },
> { NULL, /*illegal*/0, 0, NULL },
> @@ -1118,6 +1120,14 @@
>
> /* ARGSUSED */
> void
> +setifname(const char *val, int ignored)
> +{
> + ifr.ifr_data = (caddr_t)val;
> + if (ioctl(s, SIOCSIFNAME, &ifr) < 0)
> + warn("SIOCSIFNAME");
> +}
> +/* ARGSUSED */
> +void
> setifipdst(const char *addr, int ignored)
> {
> in_getaddr(addr, DSTADDR);
> --- /usr/include/sys/sockio.h.origSat Apr 17 14:33:11 2010
> +++ /usr/include/sys/sockio.h Sat Apr 17 14:32:41 2010
> @@ -179,6 +179,8 @@
> #define SIOCSLIFPHYRTABLEID _IOW('i', 161, struct ifreq) /* set tunnel
> VRF id */
> #define SIOCGLIFPHYRTABLEID _IOWR('i', 162, struct ifreq) /* get tunnel
> id */
>
> +#define SIOCSIFNAME _IOW('i', 163, struct ifreq) /* set interface name */
> +
> #define SIOCSVH _IOWR('i', 245, struct ifreq) /* set carp
> param */
> #define SIOCGVH _IOWR('i', 246, struct ifreq) /* get carp
> param */
Re: network interface renaming diff
> Date: Mon, 19 Apr 2010 13:50:55 +0200 > From: Otto Moerbeek > > On Mon, Apr 19, 2010 at 02:34:55PM +0300, Gregory Edigarov wrote: > > > Hello, > > > > This diff adds possibility for the network interfaces to have an > > arbitrary names. this is done via ifconfig name > > > > This enables you to have two interfaces with the same name, afaiks, or > have funny names that might confused tools. Sounds fishy to me. I'd > say we have a 'decription' field, use that to distinguish interfaces. I agree with Otto here. The interface names should match the device names in dmesg. Otherwise debugging (hardware) problems becomes a real bitch.
Re: network interface renaming diff
what problem does that solve? specifically, what problem does this solve that is not solved by interface groups? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: network interface renaming diff
On Mon, 19 Apr 2010 13:52:13 +0200 Claudio Jeker wrote: > On Mon, Apr 19, 2010 at 02:34:55PM +0300, Gregory Edigarov wrote: > > Hello, > > > > This diff adds possibility for the network interfaces to have an > > arbitrary names. this is done via ifconfig name > > > > Neat idea, but you do no sanity checking at all. So you could end up > with two interfaces with the same name (very bad) or an interface > with a name that violates the naming scheme. > Since if_xname is used in various places to identify interfaces > changing their name is dangerous. e.g. pf and the routing daemons use > interface names in the config. So it is important to do at least a > bit of sanity checking. No problem, wait for the second version then :-) -- With best regards, Gregory Edigarov
Re: network interface renaming diff
On Mon, Apr 19, 2010 at 02:34:55PM +0300, Gregory Edigarov wrote:
> Hello,
>
> This diff adds possibility for the network interfaces to have an arbitrary
> names.
> this is done via ifconfig name
>
> Please test.
> Thank you.
>
>
> --- /usr/src/sys/net/if.c.origSat Apr 17 12:42:06 2010
> +++ /usr/src/sys/net/if.c Sat Apr 17 13:27:12 2010
> @@ -1416,6 +1416,17 @@
> strlcpy(ifp->if_description, ifdescrbuf, IFDESCRSIZE);
> }
> break;
> +
> + case SIOCSIFNAME:
> + if ((error = suser (p,0)) != 0)
> + return (error);
> + error = copyinstr(ifr->ifr_data, ifnamebuf,
> + IFNAMSIZ,&bytesdone);
> + if (error == 0) {
> + (void)memset (ifp->if_xname, 0, IFNAMSIZ);
> + strlcpy(ifp->if_xname, ifnamebuf,IFNAMSIZ);
> + }
> + break;
>
> case SIOCGIFRTLABEL:
> if (ifp->if_rtlabelid &&
> --- /usr/src/sbin/ifconfig/ifconfig.c.origSat Apr 17 13:43:47 2010
> +++ /usr/src/sbin/ifconfig/ifconfig.c Sat Apr 17 14:34:15 2010
> @@ -149,6 +149,7 @@
> void setifbroadaddr(const char *, int);
> void setifdesc(const char *, int);
> void unsetifdesc(const char *, int);
> +void setifname(const char *, int);
> void setifipdst(const char *, int);
> void setifmetric(const char *, int);
> void setifmtu(const char *, int);
> @@ -465,6 +466,7 @@
> { "descr", NEXTARG,0, setifdesc },
> { "-description", 1,0, unsetifdesc },
> { "-descr", 1, 0, unsetifdesc },
> + { "name", 1, 0, setifname},
> { NULL, /*src*/ 0, 0, setifaddr },
> { NULL, /*dst*/ 0, 0, setifdstaddr },
> { NULL, /*illegal*/0, 0, NULL },
> @@ -1118,6 +1120,14 @@
>
> /* ARGSUSED */
> void
> +setifname(const char *val, int ignored)
> +{
> + ifr.ifr_data = (caddr_t)val;
> + if (ioctl(s, SIOCSIFNAME, &ifr) < 0)
> + warn("SIOCSIFNAME");
> +}
> +/* ARGSUSED */
> +void
> setifipdst(const char *addr, int ignored)
> {
> in_getaddr(addr, DSTADDR);
> --- /usr/include/sys/sockio.h.origSat Apr 17 14:33:11 2010
> +++ /usr/include/sys/sockio.h Sat Apr 17 14:32:41 2010
> @@ -179,6 +179,8 @@
> #define SIOCSLIFPHYRTABLEID _IOW('i', 161, struct ifreq) /* set tunnel
> VRF id */
> #define SIOCGLIFPHYRTABLEID _IOWR('i', 162, struct ifreq) /* get tunnel
> id */
>
> +#define SIOCSIFNAME _IOW('i', 163, struct ifreq) /* set interface name */
> +
> #define SIOCSVH _IOWR('i', 245, struct ifreq) /* set carp
> param */
> #define SIOCGVH _IOWR('i', 246, struct ifreq) /* get carp
> param */
>
>
> --
> With best regards,
> Gregory Edigarov
This enables you to have two interfaces with the same name, afaiks, or
have funny names that might confused tools. Sounds fishy to me. I'd
say we have a 'decription' field, use that to distinguish interfaces.
-Otto
Re: network interface renaming diff
On Mon, Apr 19, 2010 at 02:34:55PM +0300, Gregory Edigarov wrote:
> Hello,
>
> This diff adds possibility for the network interfaces to have an arbitrary
> names.
> this is done via ifconfig name
>
Neat idea, but you do no sanity checking at all. So you could end up with
two interfaces with the same name (very bad) or an interface with a name
that violates the naming scheme.
Since if_xname is used in various places to identify interfaces changing
their name is dangerous. e.g. pf and the routing daemons use interface
names in the config. So it is important to do at least a bit of sanity
checking.
> Please test.
> Thank you.
>
>
> --- /usr/src/sys/net/if.c.origSat Apr 17 12:42:06 2010
> +++ /usr/src/sys/net/if.c Sat Apr 17 13:27:12 2010
> @@ -1416,6 +1416,17 @@
> strlcpy(ifp->if_description, ifdescrbuf, IFDESCRSIZE);
> }
> break;
> +
> + case SIOCSIFNAME:
> + if ((error = suser (p,0)) != 0)
> + return (error);
> + error = copyinstr(ifr->ifr_data, ifnamebuf,
> + IFNAMSIZ,&bytesdone);
> + if (error == 0) {
> + (void)memset (ifp->if_xname, 0, IFNAMSIZ);
> + strlcpy(ifp->if_xname, ifnamebuf,IFNAMSIZ);
> + }
> + break;
>
> case SIOCGIFRTLABEL:
> if (ifp->if_rtlabelid &&
> --- /usr/src/sbin/ifconfig/ifconfig.c.origSat Apr 17 13:43:47 2010
> +++ /usr/src/sbin/ifconfig/ifconfig.c Sat Apr 17 14:34:15 2010
> @@ -149,6 +149,7 @@
> void setifbroadaddr(const char *, int);
> void setifdesc(const char *, int);
> void unsetifdesc(const char *, int);
> +void setifname(const char *, int);
> void setifipdst(const char *, int);
> void setifmetric(const char *, int);
> void setifmtu(const char *, int);
> @@ -465,6 +466,7 @@
> { "descr", NEXTARG,0, setifdesc },
> { "-description", 1,0, unsetifdesc },
> { "-descr", 1, 0, unsetifdesc },
> + { "name", 1, 0, setifname},
> { NULL, /*src*/ 0, 0, setifaddr },
> { NULL, /*dst*/ 0, 0, setifdstaddr },
> { NULL, /*illegal*/0, 0, NULL },
> @@ -1118,6 +1120,14 @@
>
> /* ARGSUSED */
> void
> +setifname(const char *val, int ignored)
> +{
> + ifr.ifr_data = (caddr_t)val;
> + if (ioctl(s, SIOCSIFNAME, &ifr) < 0)
> + warn("SIOCSIFNAME");
> +}
> +/* ARGSUSED */
> +void
> setifipdst(const char *addr, int ignored)
> {
> in_getaddr(addr, DSTADDR);
> --- /usr/include/sys/sockio.h.origSat Apr 17 14:33:11 2010
> +++ /usr/include/sys/sockio.h Sat Apr 17 14:32:41 2010
> @@ -179,6 +179,8 @@
> #define SIOCSLIFPHYRTABLEID _IOW('i', 161, struct ifreq) /* set tunnel
> VRF id */
> #define SIOCGLIFPHYRTABLEID _IOWR('i', 162, struct ifreq) /* get tunnel
> id */
>
> +#define SIOCSIFNAME _IOW('i', 163, struct ifreq) /* set interface name */
> +
> #define SIOCSVH _IOWR('i', 245, struct ifreq) /* set carp
> param */
> #define SIOCGVH _IOWR('i', 246, struct ifreq) /* get carp
> param */
>
--
:wq Claudio
network interface renaming diff
Hello,
This diff adds possibility for the network interfaces to have an arbitrary
names.
this is done via ifconfig name
Please test.
Thank you.
--- /usr/src/sys/net/if.c.orig Sat Apr 17 12:42:06 2010
+++ /usr/src/sys/net/if.c Sat Apr 17 13:27:12 2010
@@ -1416,6 +1416,17 @@
strlcpy(ifp->if_description, ifdescrbuf, IFDESCRSIZE);
}
break;
+
+ case SIOCSIFNAME:
+ if ((error = suser (p,0)) != 0)
+ return (error);
+ error = copyinstr(ifr->ifr_data, ifnamebuf,
+ IFNAMSIZ,&bytesdone);
+ if (error == 0) {
+ (void)memset (ifp->if_xname, 0, IFNAMSIZ);
+ strlcpy(ifp->if_xname, ifnamebuf,IFNAMSIZ);
+ }
+ break;
case SIOCGIFRTLABEL:
if (ifp->if_rtlabelid &&
--- /usr/src/sbin/ifconfig/ifconfig.c.orig Sat Apr 17 13:43:47 2010
+++ /usr/src/sbin/ifconfig/ifconfig.c Sat Apr 17 14:34:15 2010
@@ -149,6 +149,7 @@
void setifbroadaddr(const char *, int);
void setifdesc(const char *, int);
void unsetifdesc(const char *, int);
+void setifname(const char *, int);
void setifipdst(const char *, int);
void setifmetric(const char *, int);
void setifmtu(const char *, int);
@@ -465,6 +466,7 @@
{ "descr", NEXTARG,0, setifdesc },
{ "-description", 1,0, unsetifdesc },
{ "-descr", 1, 0, unsetifdesc },
+ { "name", 1, 0, setifname},
{ NULL, /*src*/ 0, 0, setifaddr },
{ NULL, /*dst*/ 0, 0, setifdstaddr },
{ NULL, /*illegal*/0, 0, NULL },
@@ -1118,6 +1120,14 @@
/* ARGSUSED */
void
+setifname(const char *val, int ignored)
+{
+ ifr.ifr_data = (caddr_t)val;
+ if (ioctl(s, SIOCSIFNAME, &ifr) < 0)
+ warn("SIOCSIFNAME");
+}
+/* ARGSUSED */
+void
setifipdst(const char *addr, int ignored)
{
in_getaddr(addr, DSTADDR);
--- /usr/include/sys/sockio.h.orig Sat Apr 17 14:33:11 2010
+++ /usr/include/sys/sockio.h Sat Apr 17 14:32:41 2010
@@ -179,6 +179,8 @@
#defineSIOCSLIFPHYRTABLEID _IOW('i', 161, struct ifreq) /* set tunnel
VRF id */
#defineSIOCGLIFPHYRTABLEID _IOWR('i', 162, struct ifreq) /* get tunnel
id */
+#define SIOCSIFNAME _IOW('i', 163, struct ifreq) /* set interface name */
+
#defineSIOCSVH _IOWR('i', 245, struct ifreq) /* set carp
param */
#defineSIOCGVH _IOWR('i', 246, struct ifreq) /* get carp
param */
--
With best regards,
Gregory Edigarov
Re: New intel X driver requires testing.
On Sun, 11 Apr 2010 18:47:45 +0100 Owain Ainsworth
wrote:
> The tarball that may be found at http://xenocara.org/intel-current.tgz
> contains an update to the intel 2.9.1 driver (the last one that
> supported userland modesetting) with a load of backports for bugfixes
> and performance improvements from drivers up to 2.11.
>
Note: The monitor is an old Sun CRT, so no DCC2 and probably limited
DCC1 if any. Intel drivers are odd about dcc.
dmesg and Xorg.0.log at the end.
Gem kernel built with:
option INTELDRM_GEM
option DRMDEBUG
As before, when not limiting the resolution and refresh, video will
not play. All you get is a blue box where the video should be. It's
no worse than before, but unfortunately, there's no improvement.
This is most likely caused by limited video ram.
By default, graphics mode comes up at 1600x1...@75
Video always plays perfectly if running at 1280x1...@75
After startx, X comes up in default graphics mode (higher resolution)
and then switches to preferred graphics mode, set through .xinitrc
with `xrandr -s 1280x1024 -r 75`
Prior to installing the new driver, you could not visually see or
hear the resolution switch. You gotta love the "click" of crt's to
tell the mode has changed.
INTERMITTENT CRASH:
This bug existed in the previous/current driver, so it's not new to
the new driver being tested. It's intermittent and only happens about
once every dozen or two power cycles.
With the old driver, on occasion, startx would just result in loss of
video signal and keyboard. The monitor would be left searching for
an input source (it's a multi-input crt), so the video card itself had
obviously shut down completely.
With the new driver, on occasion, startx just results in a black
screen and loss of keyboard. This is actually a slight improvement in
one sense, since the video card doesn't go completely dead.
NOTE: Without the gem-enabled kernel, this crash is consistent. Of
course, the embarrassing part is I figured this out by not paying
attention. I doubt a crash dump from this would be useful, but if so,
let me know.
In both cases, you can hear the initial "click" to graphics mode just
before everything goes down the drain.
In both cases, the system is still available over the network, so
shutting it down properly is possible, and it even responds to the
power button (auto shutdown). Also when you ssh into it, you can
see that X is not running.
It's worth noting these IBM NetVista machines are a bit wonky when
it comes to graphics. Though they all have an AGP slot, you basically
had to pay extra to have it enabled in the bios. I actually have both
the enabled and disabled models, and this crash only happens on the
model where the AGP is enabled. It's tough to blame the driver for
what might be a dodgy implementation on the hardware level.
REPEATABLE CRASH:
1.) start playing a video with mplayer with no ~/.mplayer/conf)
2.) change video playback to full screen mode ('f')
3.) Vitrual Terminal Switch To Text Mode: CTL-ALT-F1
4.) Vitrual Temrinal Switch To Graphcis Mode: CTL-ALT-F5
--still working fine at this point
5.) Vitrual Terminal Switch To Text Mode: CTL-ALT-F1
6.) Vitrual Temrinal Switch To Graphcis Mode: CTL-ALT-F5
--the X display is hosed and X crashes in a weird way
7.) Vitrual Terminal Switch To Text Mode: CTL-ALT-F1
--sitting at the shell prompt with crash message
8.) Attempt restarting X with startx
--system locks up completely. not accesible via network.
This is repeatable with or without a video playing. In other words,
the second virtual terminal switch to text mode always hoses the
running X server. But the first switch works fine.
I can get a crash dump if you want it.
OpenBSD 4.7-current (GENERIC_GEM) #0: Sat Apr 17 20:09:02 PDT 2010
j...@lion.foo.bar:/usr/src/sys/arch/i386/compile/GENERIC_GEM
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz ("GenuineIntel" 686-class) 2.40 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,SBF,CNXT-ID,xTPR
real mem = 2137550848 (2038MB)
avail mem = 2062049280 (1966MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/10/05, BIOS32 rev. 0 @ 0xfd844, SMBIOS
rev. 2.31 @ 0xf00f0 (51 entries)
bios0: vendor IBM version "24KT55AUS" date 05/10/2005
bios0: IBM 8310XXS
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP TCPA APIC BOOT
acpi0: wakeup devices USB1(S3) USB2(S3) USB3(S3) USBE(S3) SLOT(S5) KBC_(S3)
COMA(S5) COMB(S5)
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 a
Completing softraid support (sparc/sparc64 ramdisk)
Hi,
This diff adds missing bits for softraid support into sparc/sparc64
ramdisks.
Tested on my Blade 150, bsd.rd didn't overflow.
Comments? OKs?
ciao,
David
Index: distrib/sparc64/bsd.rd/list
===
RCS file: /cvs/src/distrib/sparc64/bsd.rd/list,v
retrieving revision 1.35
diff -N -u -p distrib/sparc64/bsd.rd/list
--- distrib/sparc64/bsd.rd/list 4 Apr 2010 18:35:51 - 1.35
+++ distrib/sparc64/bsd.rd/list 19 Apr 2010 06:42:08 -
@@ -55,6 +55,7 @@ LINK instbin usr/bin/gzip
usr/bin/gunzip usr/bin/g
LINK instbin usr/bin/less usr/bin/more
LINK instbin usr/bin/sed
LINK instbin sbin/sysctl
+LINK instbin sbin/bioctl
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIALcd dev; sh MAKEDEV ramdisk
Index: distrib/sparc64/ramdisk/list
===
RCS file: /cvs/src/distrib/sparc64/ramdisk/list,v
retrieving revision 1.33
diff -N -u -p distrib/sparc64/ramdisk/list
--- distrib/sparc64/ramdisk/list31 Mar 2010 17:51:42 - 1.33
+++ distrib/sparc64/ramdisk/list19 Apr 2010 06:42:08 -
@@ -50,6 +50,7 @@ LINK instbin usr/bin/gzip
usr/bin/gunzip usr/bin/g
LINK instbin usr/bin/less usr/bin/more
LINK instbin usr/bin/sed
LINK instbin sbin/sysctl
+LINK instbin sbin/bioctl
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIALcd dev; sh MAKEDEV ramdisk
Index: distrib/sparc64/ramdiskB/list
===
RCS file: /cvs/src/distrib/sparc64/ramdiskB/list,v
retrieving revision 1.27
diff -N -u -p distrib/sparc64/ramdiskB/list
--- distrib/sparc64/ramdiskB/list 31 Mar 2010 17:51:42 - 1.27
+++ distrib/sparc64/ramdiskB/list 19 Apr 2010 06:42:08 -
@@ -48,6 +48,7 @@ LINK instbin usr/bin/gzip
usr/bin/gunzip usr/bin/g
LINK instbin usr/bin/less usr/bin/more
LINK instbin usr/bin/sed
LINK instbin sbin/sysctl
+LINK instbin sbin/bioctl
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIALcd dev; sh MAKEDEV ramdisk
Index: sys/arch/sparc/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/sparc/conf/RAMDISK,v
retrieving revision 1.66
diff -N -u -p sys/arch/sparc/conf/RAMDISK
--- sys/arch/sparc/conf/RAMDISK 28 Jul 2009 12:47:34 - 1.66
+++ sys/arch/sparc/conf/RAMDISK 19 Apr 2010 06:43:21 -
@@ -24,6 +24,7 @@ optionCD9660 # ISO 9660 + Rock Ridge
file system
option INET# IP + ICMP + TCP + UDP
#optionINET6 # IPv6 (needs INET)
option BOOT_CONFIG # add support for boot -c
+option CRYPTO # Cryptographic framework
# Options for variants of the Sun SPARC architecture.
# At least one is required.
Index: sys/arch/sparc64/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/sparc64/conf/RAMDISK,v
retrieving revision 1.97
diff -N -u -p sys/arch/sparc64/conf/RAMDISK
--- sys/arch/sparc64/conf/RAMDISK 3 Apr 2010 00:53:30 - 1.97
+++ sys/arch/sparc64/conf/RAMDISK 19 Apr 2010 06:43:22 -
@@ -30,6 +30,7 @@ optionUDF # UDF (DVD) file system
option INET# IP + ICMP + TCP + UDP
option INET6 # IPv6 (needs INET)
option BOOT_CONFIG # add support for boot -c
+option CRYPTO # Cryptographic framework
option WSEMUL_SUN # provide sun terminal emulation; required
option WSEMUL_NO_VT100 # do not provide vt100 terminal emulation
