Re: How do I daemonize a process?
Garrett Cooper wrote: >As the subject suggests I'm trying to determine how I can daemonize > a C process, outside of using the rc infrastructure, so that it won't > exit when the TTY exists. Does anyone know any quick references or examples? > Thanks, > -Garrett The proper way to do this is to use the setsid() function. If it is somehow not available on one of your target system, some people use a hack which consists in calling fork() two times to daemonize the process; that is supposed to work too. Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: network stack problem in sparc64?
Maksim Yevmenkin wrote: > Maksim Yevmenkin wrote: > >Borja Marcos wrote: > >>Hello, > >> > >>I saw this some time ago but always forgot to report it. > >> > >>I'm running a pair of machines with FreeBSD/sparc64 (various versions, > >>one of them is running -STABLE now), and I've seen a problem with the > >>network stack. > >> > >>Looking at buffer and window sizes, > >> > >>earendil# sysctl net.inet.tcp|fgrep space > >>net.inet.tcp.sendspace: 0 > >>net.inet.tcp.recvspace: 0 > >> > >>earendil# sysctl net.inet.udp > >>net.inet.udp.checksum: 1 > >>net.inet.udp.maxdgram: 0 > >>net.inet.udp.recvspace: 0 > >> > >>When I try to modify them, it doesn't work at all. For example, trying > >>to run nfcapd/nfsen in a sparc64 box, I get an error for a > >>setsockopt() call > >> > >>earendil# /usr/local/etc/rc.d/nfsen start > >>Starting nfsenStarting nfcpad: upstream1setsockopt(SO_RCVBUF,20): > >>Invalid argument > >>Terminated due to errors. > >>nfcapd exec error: exit: 255, signal: 0, coredump: 0 > >> > >> > >>For x86 machines the values are correctly reported and they work as > >>expected. > >> > >>I have been poking Google for this but I haven't seen any mention of > >>this. > > > >hmmm... how about this (untested) patch? > > > >--- tcp_usrreq.c.orig Fri Nov 4 12:26:14 2005 > >+++ tcp_usrreq.cMon Sep 25 09:31:42 2006 > >@@ -1161,10 +1161,10 @@ > > * sizes, respectively. These are obsolescent (this information should > > * be set by the route). > > */ > >-u_long tcp_sendspace = 1024*32; > >+inttcp_sendspace = 1024*32; > > SYSCTL_INT(_net_inet_tcp, TCPCTL_SENDSPACE, sendspace, CTLFLAG_RW, > > &tcp_sendspace , 0, "Maximum outgoing TCP datagram size"); > >-u_long tcp_recvspace = 1024*64; > >+inttcp_recvspace = 1024*64; > > SYSCTL_INT(_net_inet_tcp, TCPCTL_RECVSPACE, recvspace, CTLFLAG_RW, > > &tcp_recvspace , 0, "Maximum incoming TCP datagram size"); > > > >--- udp_usrreq.c.orig Wed Sep 13 11:19:26 2006 > >+++ udp_usrreq.cMon Sep 25 09:32:00 2006 > >@@ -923,12 +923,12 @@ > >return (error); > > } > > > >-u_long udp_sendspace = 9216; /* really max datagram size */ > >+intudp_sendspace = 9216; /* really max datagram size */ > >/* 40 1K datagrams */ > > SYSCTL_INT(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW, > > &udp_sendspace, 0, "Maximum outgoing UDP datagram size"); > > > >-u_long udp_recvspace = 40 * (1024 + > >+intudp_recvspace = 40 * (1024 + > > #ifdef INET6 > > sizeof(struct sockaddr_in6) > > #else > > > actually, it was fixed in -current long time ago, > > === > Revision 1.128 / (download) - annotate - [select for diffs], Wed Dec 14 > 22:27:48 2005 UTC (9 months, 1 week ago) by mux > Branch: MAIN > Changes since 1.127: +2 -2 lines > Diff to previous 1.127 (colored) > > Fix a bunch of SYSCTL_INT() that should have been SYSCTL_ULONG() to > match the type of the variable they are exporting. > > Spotted by: Thomas Hurst <[EMAIL PROTECTED]> > MFC after:3 days > === > > i guess mfc did not happen in 3 days. Oops! I'm terribly sorry about this. Unless there is an objection, I'll MFC those ASAP. Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
maksim yevmenkin wrote: > Maxime Henrion wrote: > >Dag-Erling Sm?rgrav wrote: > >>Maksim Yevmenkin <[EMAIL PROTECTED]> writes: > >>>so far i only got one (successful) report. would people please give > >>>it a try to see if work, so i can commit it. > >>Please commit it. I don't see how it can do any harm. > > > >Yes please; I'd like to see this patch in HEAD as soon as possible so > >that we can have as much coverage as possible since this is the kind of > >fix that will be very desirable to MFC for 6.2-RELEASE. > > patch was committed to head yesterday. Yeah, I just saw it, I was quite behind with my mail. Thanks! > >BTW, does your patch also fix similar problems with kbdmux(4) and the > >geli mountroot prompt? > > yes, it should. please let me know if you still have this kind of > problems with kbdmux(4) and atkbd(4) Great. I haven't had the time to look at the patch yet, but can you foresee any problem with MFC'ing it or would you consider it safe? Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Dag-Erling Sm?rgrav wrote: > Maksim Yevmenkin <[EMAIL PROTECTED]> writes: > > so far i only got one (successful) report. would people please give > > it a try to see if work, so i can commit it. > > Please commit it. I don't see how it can do any harm. Yes please; I'd like to see this patch in HEAD as soon as possible so that we can have as much coverage as possible since this is the kind of fix that will be very desirable to MFC for 6.2-RELEASE. BTW, does your patch also fix similar problems with kbdmux(4) and the geli mountroot prompt? Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Userland version of struct vnode ?
Pranav Peshwe wrote: > Hello, > Why is the 'Userland version' struct vnode created i.e struct > xvnode (in vnode.h) ? The comment says that it is 'for sysctl'.There are > also userland versions of struct file and struct tty.Can anybody please > explain about their use ? Those structures exist so that changing the size of the kernel struct vnode has no impact for the userland tools. If the sysctls were giving a struct vnode instead of a struct xvnode, every change in the layout or size of struct vnode would break the ABI and require a rebuild of all the userland tools gathering vnodes from the sysctl. It also allows the sysctl code to only give the meaningful fields back to userland, reducing the amount of memory that needs to be copied. Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATI drivers for FreeBSD - anything?
Albert Vest wrote: > On Sat, 19 Nov 2005 01:58:25 +0200 (EET) > Vladimir Kushnir <[EMAIL PROTECTED]> wrote: > > > Hi all, > > Is there any project on FreeBSD wrapper for ATI Linux drivers (like > > nVidia's used to be)? If so - I'd be more than happy to test (sorry I can > > hardly write it myself). > > > > Regards, > > Vladimir > > I too would welcome this, mainly for ATI sound but also for video. > > I see the x11/nvidia-driver port can still be built with LINUX compatibility > turned on; maybe if we "make extract" with LINUX=yes, the source code will > contain some hints to how it can be done? The Linux compatibility in the nvidia-driver has nothing to do with a wrapper to run Linux drivers; nVidia releases a build of this driver for FreeBSD. The Linux compatibility option is here to install nVidia's Linux OpenGL libraries so that Linux binaries can run with FreeBSD's driver. This is possible because nVidia's OpenGL libraries communicate with the driver by using /dev/nvidia and the FreeBSD driver offers the same interface. In short, there is no easy way to use the ATI drivers for Linux under FreeBSD. Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d cleanup
Giorgos Keramidas wrote:
> On 2005-08-01 13:55, John Baldwin <[EMAIL PROTECTED]> wrote:
> >On Monday 01 August 2005 01:29 pm, [EMAIL PROTECTED] wrote:
> >> This patch effects most of the rc.d scripts that utilize simple IF
> >> statements, converting them to logical AND/OR's instead. For example:
> >>
> >> if [ ! -f foo ]
> >> then
> >> bar
> >> fi
> >>
> >> Would simply become:
> >>
> >> [ -f foo ] || bar
> >>
> >> The exception (but not the rule) is for any situation where ELIF/ELSE is
> >> required. In other words any exclusive conditional situations.
> >>
> >> I also applied this notion to many simple blocks of code wrapped around
> >> non-exclusive IF statements, such as:
> >>
> >> [ -f foo ] && {
> >>command-list
> >>[...]
> >> }
> >
> > The argument I would have against this is that it is a lot easier to
> > read the 'if foo; then ; fi' style, esp. for folks used to using C,
> > etc. Shell scripts don't need to be overly obfuscated.
>
> Ditto. The if/then blocks may look superficial at first and entirely
> redundant, but they really work much better then code like this:
>
> [ -f foo ] || bar
>
> has to be extended to form a multiline statement. Now, I know that one
> can always write:
>
> [ -f foo ] || {
> [ -d bar ] && {
> blah
> }
> }
>
> But this quickly gets too ugly for my taste. The equivalent if/then
> blocks:
>
> if [ ! -f foo ]; then
> if [ -d bar ]; then
> blah
> fi
> fi
>
> or even, the similar:
>
> if [ ! -f foo ] && [ -d bar ]; then
> blah
> fi
>
> Look much much prettier to the eyes of one who knows how to read both
> shell scripts and C code.
Thirded. I far prefer the bigger C-like if statements and think this
patch is a huge code churn for what is basically code obfuscation.
Cheers,
Maxime
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bus error in strsep
Stefan Sperling wrote: > On Wed, Jul 06, 2005 at 12:10:23PM -0700, Maksim Yevmenkin wrote: > > Maksim Yevmenkin wrote: > > >>char *c = "whats:your:name:buddy?"; > > > > > > that is not read only copy. you can not write > > >into it. replace it with > > > > made type. that should read "that is read only copy" :) > > Dark corners of C... So it's my own fault, as usual :) > thanks a lot :) Or you can be a bad guy and compile with GCC and -fwritable-strings so that it puts the const string into a read-write section :-). This is an absolutely evil hack, of course. Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
Devon H. O'Dell wrote: > On Mon, Mar 28, 2005 at 01:42:16PM -0500, c0ldbyte wrote: > > On Mon, 28 Mar 2005, mohamed aslan wrote: > > > > >hi guys > > >it's my first post here, BTW i was a Linux hacker and Linux kernel > > >mailing list member for 3 years. > > > > > >and I've a comment here , i think the freebsd kernel source files > > >aren't well organized as Linux ones. > > > > Well thats nice, Didnt your mommy say once to you before "If you dont have > > nothing good to say then dont say nothing" ?. Thats not a really detailed > > look into where you think the files are not well organized. Personly I > > think you have had your head stuck in the Linux culture to long to comment > > on anything going on with the Freebsd code or how the system is layed out. > > Perhaps you should take a bit of your own advice `c0ldbyte'. I'm > personally sick of your condescending attitude towards everybody > on the public lists. Cut it out. Fully seconded. Even though it clearly wasn't a brilliant idea to criticize FreeBSD source code organization without giving a single reason or example, Mohamed clearly didn't deserve to be flamed like this. A bit more diplomacy wouldn't hurt here... Now responding to Mohamed, I'm really surprised to see you writing this. I've banged my head against the wall so many times to locate some piece of source code in the Linux kernel that I really cannot understand you. For the most part, I find the FreeBSD source organization simply great. There are many criticisms one can legitimally do against FreeBSD, but that one sounds just wrong. Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Runtime loading
db wrote: > Hi all > > In my C++ program I need to load some files/classes at runtime, so that users > can add "plugins" without recompilling my program. What functions should I > use? I'm using FreeBSD 5.3-beta2 btw. I'm not sure about C++, though I guess you could use the same functions as in C. If that's true, then you should use the dlopen() family of functions. They are quite portable, since you'll find the same functions under all the *BSD, Linux and Solaris. Be aware that with Linux and Solaris, those functions are located in libdl, while they are found in libc on the *BSD systems. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on amd64/amd64
Liam J. Foy wrote:
> On Thu, 17 Jun 2004 05:47:25 -0400 (EDT)
> FreeBSD Tinderbox <[EMAIL PROTECTED]> wrote:
>
> > TB --- 2004-06-17 08:56:11 - tinderbox 2.3 running on freebsd-current.sentex.ca
> > TB --- 2004-06-17 08:56:11 - starting CURRENT tinderbox run for amd64/amd64
> > TB --- 2004-06-17 08:56:11 - checking out the source tree
> > TB --- 2004-06-17 08:56:11 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64
> > TB --- 2004-06-17 08:56:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
> > TB --- 2004-06-17 09:01:06 - building world (CFLAGS=-O2 -pipe)
> > TB --- 2004-06-17 09:01:06 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src
> > TB --- 2004-06-17 09:01:06 - /usr/bin/make -B buildworld
> > >>> Rebuilding the temporary build tree
> > >>> stage 1.1: legacy release compatibility shims
> > >>> stage 1.2: bootstrap tools
> > >>> stage 2.1: cleaning up the object tree
> > >>> stage 2.2: rebuilding the object tree
> > >>> stage 2.3: build tools
> > >>> stage 3: cross tools
> > >>> stage 4.1: building includes
> > >>> stage 4.2: building libraries
> > >>> stage 4.3: make dependencies
> > >>> stage 4.4: building everything
> > [...]
> > cc -O2 -pipe-o nos-tun nos-tun.o
> > gzip -cn /tinderbox/CURRENT/amd64/amd64/src/sbin/nos-tun/nos-tun.8 > nos-tun.8.gz
> > ===> sbin/pfctl
> > cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes
> > -I/tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl/../../contrib/pf/pfctl
> > -I/tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl/../../sys/contrib/pf -DENABLE_ALTQ
> > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c
> > /tinderbox/CURRENT/amd64/amd64/src/contrib/pf/pfctl/pfctl.c
> > cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes
> > -I/tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl/../../contrib/pf/pfctl
> > -I/tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl/../../sys/contrib/pf -DENABLE_ALTQ
> > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c parse.c
> > cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes
> > -I/tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl/../../contrib/pf/pfctl
> > -I/tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl/../../sys/contrib/pf -DENABLE_ALTQ
> > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c
> > /tinderbox/CURRENT/amd64/amd64/src/contrib/pf/pfctl/pfctl_parser.c
> > /tinderbox/CURRENT/amd64/amd64/src/contrib/pf/pfctl/pfctl_parser.c: In function
> > `print_status':
> > /tinderbox/CURRENT/amd64/amd64/src/contrib/pf/pfctl/pfctl_parser.c:559: warning:
> > long long int format, long unsigned int arg (arg 3)
> > *** Error code 1
> >
> > Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin/pfctl.
> > *** Error code 1
> >
> > Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin.
> > *** Error code 1
> >
> > Stop in /tinderbox/CURRENT/amd64/amd64/src.
> > *** Error code 1
> >
> > Stop in /tinderbox/CURRENT/amd64/amd64/src.
> > *** Error code 1
> >
> > Stop in /tinderbox/CURRENT/amd64/amd64/src.
> > TB --- 2004-06-17 09:47:25 - WARNING: /usr/bin/make returned exit code 1
> > TB --- 2004-06-17 09:47:25 - ERROR: failed to build world
> > TB --- 2004-06-17 09:47:25 - tinderbox aborted
> >
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
> The following patch should solve this problem I believe:
>
> --- /usr/src/contrib/pf/pfctl/pfctl_parser.c Thu Jun 17 13:20:07 2004
> +++ /home/liamfoy/pfctl_parser.c Thu Jun 17 13:26:16 2004
> @@ -555,7 +555,7 @@
> printf(" %-25s %14u %14s\n", "current entries",
> s->src_nodes, "");
> for (i = 0; i < SCNT_MAX; i++) {
> - printf(" %-25s %14lld ", pf_scounters[i],
> + printf(" %-25s %14lu ", pf_scounters[i],
> s->scounters[i]);
> if (runtime > 0)
> printf("%14.1f/s\n",
>
>
>
> Correct me if I am wrong :), would someone care to commit it if its fine?
It's actually not correct. The scounters[i] here is of type u_int64_t,
so long is not the correct format here (longs are 32bit on many 32bit
architectures such as FreeBSD/i386). The correct format to use here is
%llu (long long's are at least 64bit), with a cast to (unsigned long long),
but most of the time we prefer to use %ju and a cast to uintmax_t. C99
also provides macros for fixed-size type formats, and we could thus use
the PRIu64 macro here, but we don't use them because they're too ugly.
I won't commit a fix because this code is in contrib/ and is maintained
by Max Laier (see /usr/src/MAINTAINERS). I'm CC'ing him this mail though.
Cheers,
Maxime
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/fre
Re: Where is FreeBSD going?
Hi all, Since several people actually thought this mail was written by me, I'm replying here to tell it wasn't. This mail was sent by the same guy who periodically impersonate one of the FreeBSD committers to rant about the project. His mail doesn't reflect my thoughts at all. Please all let this thread die. Thanks, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BUS DMA sync
Vincent Jardin wrote: > Hi, > > I try to understand the purpose of the PRE sync (BUS_DMASYNC_PREREAD, > BUS_DMASYNC_PREWRITE). > > I understand POST synchronization (BUS_DMASYNC_POSTREAD, > BUS_DMASYNC_POSTWRITE) when a device to memory or a memory to device > transfert needs to be synchronized. However, what does a synchronization > before a transfert mean ? With common architectures where FreeBSD runs on, only BUS_DMASYNC_PREWRITE and BUS_DMASYNC_POSTREAD are actually meaningful and needed. It's good style to use the two others where appriopriate though, because some more exotic architecture might require it some day. BUS_DMASYNC_PREWRITE is used to synchronize before there's a DMA tranfer from host memory to a device. It's needed to ensure the device will read up-to-date memory, because recent changes to memory might still sit in a cache, so it actually flushes the memory cache. BUS_DMASYNC_POSTREAD is used to synchronize after a DMA transfer from the device to host memory. It's needed to ensure the software will get up-to-date memory as written by the device, and not outdated memory sitting in a cache, so it actually invalidates the memory cache. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell fast ethernet 3ccfe575bt-d
M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Sandeep Kumar Davu <[EMAIL PROTECTED]> writes: > : I was intalling freebsd on laptop and could not find the drivers for > : 3ccfe575bt-d fast ethernet 10/100base-tx ethernet card. Could anyone please > : enligten me where can I find the driver for this card. > > /usr/src/sys/dev/xl in current. nowhere on 4.x stable. The sources for the xl(4) driver live in /usr/src/sys/pci, not in /usr/src/sys/dev/xl which doesn't exist. The driver is contained in the if_xl.c and if_xlreg.h files. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI ID Patch for Intel Ether Express Pro 100 VE (82801BA)
Tom Alsberg wrote: > Having got a new machine here a few days ago, an Intel ICH D865 PERL > board based Pentium IV machine, with an on-board Intel EtherExpress > Pro 100 VE, it failed to detect the network adapter. > > Seeing that it is an EtherExpress Pro 100, I though the fxp module > should work with it, and found out that the PCI ID (8086:1050) just > isn't recognized as one (new chip or something, apparently). Patch committed, thanks! Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: D_KQFILTER & ltmdm: Patch for review?
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "M. Warner Losh" <[EMAIL PROTECTED]> writes:
> : : static struct cdevsw sio_cdevsw = {
> : : +#if __FreeBSD_version >= 500104 /* >= 20030303 */
> :
> : This syntax works even for old versions of FreeBSD. You can make it
> : safe by including all the noFoo functions. phk got rid of them
> : because it is safe in >= 500104 to do that. Since you want to run on
> : multiple versions, it would be better/safer to do that.
[...]
FWIW, the correct __FreeBSD_version number for the cdevsw initialization
changes is 500105.
Cheers,
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
Terry Lambert wrote: > Maxime Henrion wrote: > > With kenv(1) you can modify kernel environment variables, which hold the > > tunables. Previously, you could only set those at boot time. > > Note that there are some values which are used to determine the > size of KVA space allocations, and changing them after boot, > even if it's permitted, will have no real effect. > > For example, you can change the value of "maxfiles" with a sysctl, > but doing so will not increase the number of simultaneous network > connections your system will support, since the reserved space for > tcpcb's and sockets is not increased. Yes. > The kernel environment is most useful for diagnostic porposes, and > for use in the way descrived in this thread -- to provide a means > of passing parameters that should not be parameters to modules that > should not need parameters in the first place. Many times, hacking > the values post-boot will have little or no effect. It's too bad > the things that will have no effect were exported as writeable, > instead of resulting in an error. I agree this is not perfect, but I don't think we should return an error though. It would be bad to start duplicating the sysctl functionality into the kernel environment. What could be nice would be to unsetenv() the environment variables after them being read and used, so that people typing kenv won't see these variables in the output and so won't be tempted to set them. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Chuck Tuffli <[EMAIL PROTECTED]> writes: > : I'm a newbie to FreeBSD and am wondering if there is a way to pass > : loadable kernel modules parameters. Under Linux, if a module had > : configurable parameters "a" and "b", you can do something like > : > :insmod module.o parameters="a:10 b:5" > : > : I noticed that some of the drivers grabed information from the > : "environment" using getenv_int(), but I couldn't seem to get this to > : work. Thanks for any thoughts. > > You can generally do this with hints and/or kernel environment > variables. However, you can't easily edit these things once you > boot. With kenv(1) you can modify kernel environment variables, which hold the tunables. Previously, you could only set those at boot time. Now you can have load time module parameters, and you can do things like unload a module, change the parameter, reload it and it will take effect immediately. This is really useful for things which need to be gathered by the module at load time, because the module can't use a sysctl for this if it's at load time. I have patches which make the IPFIREWALL_DEFAULT_TO_ACCEPT setting dynamic with kernel environment variables. So people can install FreeBSD, use the already compiled ipfw module and still change this setting. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hey, is there space for a newbie? =)
Paolo Pisati wrote: > Hi guys, > > as I said in the subject i'm a newbies of the kernel, but i used > FreeBSD for years, so when the time to write my final thesis > in my university arrived i immediately thought to help in some > way the FreeBSD group. > > Here there's a mini list of things i would like to work on, tell me > which one is available and fell free to add any other project you > think could help the FreeBSD community in general. > > -the kernel memory allocator: if i remember correctly FreeBSD still > uses a power-of-two algorithm, what do you think about a > buddy-list algo, slab allocator or something new? We have an MP-safe slab allocator in -CURRENT since some time now. > -a fs with journaling: some times ago, i would like to develop > my own fs with journaling, but right now i could even drop the > dream of my own fs and JUST port the xfs/jfs for FreeBSD.. Alexander Kabaev is working on a XFS port, and Hiten Pandya on a JFS port. > -kgi: is it dead or what? No idea :-). > any ideas is welcome =) Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Checking syscall arguments
Grahame Bowland wrote:
>
> Hi all,
>
> When implementing a syscall for FreeBSD, how do you ensure that the arguments
> you have been passed are sane? I'm interested in the following syscall:
> int setattr(char *file, struct stat *st, unsigned bitmap);
>
> As far as I can see from reading similar functions, such as fhstatfs, the
> correct way to do it is:
>
> {
> struct stat st;
> error = copyin(SCARG(uap, st), &st, sizeof(struct stat));
> if (error) { return error; }
> }
>
> Does the above code ensure that I'm safe, and I can 'trust' that there is a
> struct stat 'st' that I can access normally in the code? Obviously I can't
> trust the values contained in it, however can I be assured that I'm not going
> to overrun or anything nasty by doing the above?
Yes. If the copyin() succeeded you can assume that sizeof(struct stat)
bytes have been copied from userland. Obviously, you can't assume
anything about the content of these bytes though.
Maxime
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Kris Kennaway wrote:
> On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote:
>
> > I've got a very similar patch which I believe to be a bit more complete
> > because it also updates the MACHINE_CPU variable which lists the
> > features available on a particular CPU. I attach it to this mail.
>
> Oops, I forgot that part. How about sse2 though?
Forgot that one. Here is an updated patch. I'm quite sure that on the
Intel side, only the pentium 4 have sse2, but I don't know if any AMD
chip supports it yet. The attached patch only adds it for p4's.
Cheers,
Maxime
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -p -r1.16 bsd.cpu.mk
--- bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ bsd.cpu.mk 7 Sep 2002 01:05:43 -
@@ -28,8 +28,8 @@ CPUTYPE = ultrasparc
CPUTYPE = i686
. elif ${CPUTYPE} == "pentium"
CPUTYPE = i586
-. elif ${CPUTYPE} == "athlon"
-CPUTYPE = k7
+. elif ${CPUTYPE} == "k7"
+CPUTYPE = athlon
. endif
. endif
@@ -42,20 +42,30 @@ CPUTYPE = k7
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
+. if ${CPUTYPE} == "athlon-mp"
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == "athlon-xp"
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == "athlon-4"
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == "athlon-tbird"
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == "athlon"
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == "k6-3"
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == "k6-2"
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == "k6"
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == "k5"
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == "p4"
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == "p3"
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == "p2"
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == "i686"
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == "i586/mmx"
@@ -93,8 +103,18 @@ CFLAGS += ${_CPUCFLAGS}
# presence of a CPU feature.
.if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
+. if ${CPUTYPE} == "athlon-mp"
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon-xp"
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon-4"
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon-tbird"
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon"
+MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "k6-3"
+MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6-2"
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6"
@@ -102,7 +122,7 @@ MACHINE_CPU = mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k5"
MACHINE_CPU = k5 i586 i486 i386
. elif ${CPUTYPE} == "p4"
-MACHINE_CPU = sse i686 mmx i586 i486 i386
+MACHINE_CPU = sse2 sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == "p3"
MACHINE_CPU = sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == "p2"
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Kris Kennaway wrote:
> On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote:
>
> > `-mcpu=CPU-TYPE'
> > Tune to CPU-TYPE everything applicable about the generated code,
> > except for the ABI and the set of available instructions. The
> > choices for CPU-TYPE are `i386', `i486', `i586', `i686',
> > `pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
> > `pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
> > `athlon-4', `athlon-xp' and `athlon-mp'.
> >
> > You can also add -msse, -msse2, -m3dnow to use those extensions. It would
> > appear that our bsd.cpu.mk file is out of date and is missing the newer
> > cpu types.
>
> How about the following patch (I've only tested 'pentium3'):
[patch ripped]
I've got a very similar patch which I believe to be a bit more complete
because it also updates the MACHINE_CPU variable which lists the
features available on a particular CPU. I attach it to this mail.
Cheers,
Maxime
Index: bsd.cpu.mk
===
RCS file: /space2/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -p -r1.16 bsd.cpu.mk
--- bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ bsd.cpu.mk 11 Aug 2002 18:46:06 -
@@ -28,8 +28,8 @@ CPUTYPE = ultrasparc
CPUTYPE = i686
. elif ${CPUTYPE} == "pentium"
CPUTYPE = i586
-. elif ${CPUTYPE} == "athlon"
-CPUTYPE = k7
+. elif ${CPUTYPE} == "k7"
+CPUTYPE = athlon
. endif
. endif
@@ -42,20 +42,30 @@ CPUTYPE = k7
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
+. if ${CPUTYPE} == "athlon-mp"
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == "athlon-xp"
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == "athlon-4"
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == "athlon-tbird"
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == "athlon"
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == "k6-3"
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == "k6-2"
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == "k6"
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == "k5"
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == "p4"
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == "p3"
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == "p2"
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == "i686"
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == "i586/mmx"
@@ -93,8 +103,18 @@ CFLAGS += ${_CPUCFLAGS}
# presence of a CPU feature.
.if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
+. if ${CPUTYPE} == "athlon-mp"
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon-xp"
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon-4"
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon-tbird"
+MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "athlon"
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "k6-3"
+MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6-2"
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6"
Re: CHN_LOCK()
Evan Sarmiento wrote: > I keep on getting debug messages like this, both at startup > and right before any sound plays: > > Jun 14 23:44:38 teqnix kernel: /usr/src/sys/vm/uma_core.c:1327: could > sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:713 > heyeh, Jun 14 23:44:38 teqnix kernel: /usr/src/sys/vm/uma_core.c:1327: could > sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:713 [...] > To avoid this, I was wondering if I could change CHN_LOCK() to use > spin locks instead of sleeping mutex locks? Of course I would > make it so that mtx_init has RECURS.. would this work? This debugging messages appear because some code calls malloc() without the M_NOWAIT flags, so if memory is not available right now, the code may sleep while holding the lock which is bad. Changing the type of the mutex to a spin mutex would not fix anything, and would make things a lot worse. You need to change the code so that it calls malloc() earlier, while it's not holding any lock, or unlock before calling malloc(), relock and deal with the race condition if it's possible. Calling malloc() with M_NOWAIT isn't a good fix as well, because there is no reason to make this code fail if memory if not available at the moment, and not have it sleep for it instead. M_NOWAIT should only be used while in interrupt context, as far as I know. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: randompid
Alexey Privalov wrote: > hi all. > > i`m trying to set randompid: > > root@land3# sysctl kern.randompid=1 > kern.randompid: 0 -> 0 > > what`s a need to set on? The value you give to this sysctl is not a boolean, it's a value used in the formula which computes the randompid. This value is sanity checked, that's why giving 1 doesn't do anything. Here is the code which is responsible for this : if (pid < 0 || pid > PID_MAX - 100) /* out of range */ pid = PID_MAX - 100; else if (pid < 2) /* NOP */ pid = 0; else if (pid < 100) /* Make it reasonable */ pid = 100; This should give you enough information to chose a good value. :-) Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: init code in dynamic libraries
Bernd Walter wrote: > How can I add initalisation code to a library without needing to > call a function in the using application? > What I saw is that libc does something like this but havn't found > the starting point of this. There are two special functions for that : _init() which will be called when the object is loaded, and _fini() which will be called when it is released. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New vhost bugs.FreeBSD.org
Hello all, The recently added cvsweb.FreeBSD.org vhost makes me think we could also have one pointing to the PR database (/cgi/query-pr-summary.cgi), for example, bugs.FreeBSD.org as the subject of this mail suggests. It would be very useful, IMO, to have a simple URL like this to access the PR database. Opinions ? Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Changing syscalls numbers
Nickolay A.Kritsky wrote: > Hi, freebsd-hackers. > > Recently I was trying to change some syscalls numbers (i.e. syscall > exit would have number 5 and syscall open would have number 1). > My thought was, that for that operation one must edit file > /usr/src/sys/kern/syscalls.master and remake world. I edited the file > named above, rebooted in single-user mode, and ran "make buildworld && > make buildkernel && make installkernel && make installworld". > Everything seems to be OK, new kernel has been built and installed (I > think it is `new', because /kernel has the creation date of "make > installkernel" and diff says it differs from /kernel.old ), but > mov eax,1 > push eax > int 80h > > still performs exit. > > Could you point me, what wrong assumptions/steps have I done? > Any help is very good. /usr/src/sys/kern/makesyscalls.sh syscalls.master Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/vm vnode_pager.c
Matthew Dillon wrote: > Well, 11% over a period of a single second, once every 30 seconds > makes sense if there are a lot of vnodes cached. I think you are > seeing the same issue, just that on -stable there is much lower > overhead. > > Basically we have two routines that are causing problems: > > ffs_sync() > qsync() (quota sync) [explanation ripped] Perhaps my problem is because of something else ; I recompiled a kernel with a different syncdelay in vfs_subr.c, 42s (sorry ;) instead of 30s. I also bumped SYNCER_MAXDELAY accordingly. But, the problem was still happening every 30s. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/vm vnode_pager.c
Matthew Dillon wrote: > > The time jump is irrelevant. It's whether you feel a glitch or not > while the sync is running that counts. I don't do profiling on a sync command, I monitore the system with ``iostat -w 1'' then I see where the jump occurs and since it occurs every 30s, I try to launch the profiling in a window around the jump as little as possible. Am I doing it wrong ? Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/vm vnode_pager.c
Matthew Dillon wrote: > > This profiled output shows the system completely idle. If > something is locking up eating cpu this profile run didn't > catch it. Ok, I'll do a new one ASAP, with a system where system cpu time jump is higher. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory allocation question
Dwayne wrote: > I'm creating an app where I want to use memory to store data so I > can get at it quickly. The problem is, I can't afford the delays that > would occur if the memory gets swapped out. Is there any way in FreeBSD > to allocate memory so that the VM system won't swap it out? > I think mlock(2) is what you want. Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sound driver changes between 4.2 and 4.3
Farooq Mela wrote: > Hi -hackers, > > Several people have made it known to me that games such as Quake2 > which ran fine with sound under the 4.2 kernel are not able to have > sound in 4.3. I have verified this myself - with quake2 under 4.3 > ktrace reports that opening /dev/dsp fails with EBUSY - even though > nothing is using /dev/dsp and other programs are able to open it and > play sound just fine immediately afterwards. Under 4.2 on the same > machine, open()ing /dev/dsp is successful and sound functions. > Figuring out what's going wrong is further complicated by the fact > that these are linux binaries and run under the linux emulator. Could > it be the linux emulator messing something up, and not the sound card? > > Since this is an issue of the userland's interface to the sound driver > and is not concerned with sound driver internals or driving a specific > card (since this problem occurs regardless of sound card), I thought I > might try and see if could fix the problem. I've not done any kernel > programming before, but I'd like to get my feet wet and this seems > like a relatively small project. Any pointers as to where to start? > Anybody else run into similar problems and try to see what is going > wrong? I ran into these problems too. On my -CURRENT system, I'm unable to get sound with mtvp (running under Linux emulation), while it was working before. I've also seen a -STABLE box unable to open the /dev/dsp file (open returns EBUSY) although both fstat and lsof didn't see any process with this file opened. This second problem was happening even when trying to ``cat /dev/dsp'' so it's probably not be related to the Linux emulation. Hope it helps, Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help to port brltty to BSD
Hello all, I have been discussing on IRC with a blind people who can't use BSD because ``brltty'', the software used to render the console tty with braille displays, doesn't appear to work on BSD. I have been experiencing troubles while trying to compile it and moreover, it uses ``/dev/vcsa0'' to get snapshots of the tty. This is a Linux-only device. However, to run on other Unices (as the author say), it can use the sysV shared memory to obtain this information by reading into ``screen'' program memory segment. Unfortunately, this is obviously not as good as with using tty snapshots as the user has to launch ``screen'' first before having access to his box, and unless we one day use screen in the install (which I doubt ;) the user will have to get help from a valid person to install BSD. I have seen that recently, a snapshot capability has been introduced in syscons in -CURRENT. Can this help to port this software ? I've thought of using snoop ttys but I'm not sure if they provide all the needed functionality. Finally, I'm running out of time these days and if someone has a bit more time free, I would really appreciate help with porting this software as it seems to me that giving access to BSD for blind people is more important than most, if not all, other features. Here is the homepage of brltty : http://www.cam.org/~nico/brltty/ Thanks, Maxime PS: If anyone has heard of any other program similar working on BSD, don't hesitate to flame me ;-) ! -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Patch to disallow the build of modules
Hi,
Here is a patch to select the modules you want and don't want.
The patch is for /usr/src/sys/modules/Makefile from RELENG_4.
Then you have to put variables in make.conf (i'm writing the patch
for defaults/make.conf) like this :
NO_KMOD_FPU=true
NO_KMOD_GNUFPU=true
...
Thanks for any review.
Maxime
--
Don't be fooled by cheap finnish imitations ; BSD is the One True Code
Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6
Public Key : http://www.epita.fr/~henrio_m/
--- /usr/src/sys/modules/Makefile Tue Mar 13 02:26:22 2001
+++ MakefileSat Mar 24 20:35:54 2001
@@ -2,7 +2,7 @@
# XXX present but broken: ip_mroute_mod pcic
-SUBDIR=accf_data accf_http agp aha amr an aue \
+_SUBDIR= accf_data accf_http agp aha amr an aue \
ccd cd9660 coda cue dc fdesc fxp if_disc if_ef if_ppp \
if_sl if_tap if_tun ip6fw ipfilter ipfw ispfw joy kernfs kue \
linux md mfs mii mlx msdos ncp pcn netgraph nfs ntfs nullfs \
@@ -12,16 +12,22 @@
# XXX some of these can move to the general case when de-i386'ed
.if ${MACHINE_ARCH} == "i386"
-SUBDIR+=aac asr bktr coff fpu gnufpu ibcs2 linprocfs mly ray splash streams \
+_SUBDIR+=aac asr bktr coff fpu gnufpu ibcs2 linprocfs mly ray splash streams \
svr4 vesa wi
.endif
.if ${MACHINE} == "pc98"
-SUBDIR+=snc
+_SUBDIR+=snc
.endif
.if ${MACHINE_ARCH} == "alpha"
-SUBDIR+=osf1
+_SUBDIR+=osf1
.endif
+
+.for kmod in ${_SUBDIR}
+.if !defined(NO_KMOD_${kmod:U})
+SUBDIR+=${kmod}
+.endif
+.endfor
.include
Re: talk(1) patch to allow 8bits characters
Matt Dillon wrote: >This is an extremely dangerous patch. A number of terminal protocols >have a 'talkback' escape sequence that allow you to write data >that the terminal then copies back as if someone typed it. I remember >using this feature quite a lot while at Berkeley to, ah, break into >people's accounts :-) > >isprintf() is in there to prevent extranious escape sequences from >blowing up the other guy's window. > -Matt I wasn't aware of this at all. I will know now, thanks :-) Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: talk(1) patch to allow 8bits characters
Michael C . Wu wrote: > On Tue, Feb 27, 2001 at 08:53:09PM +0100, Maxime Henrion scribbled: > isprint() has been broken for a long long time. Clive Lin > <[EMAIL PROTECTED]> was about to fix it. I know that > we have been slacking, but please give us some time. Of course, this was only meant as a temporary solution, if isprint() is going to be fixed soon then it's probably useless. I would like to see this working for 4.3-RELEASE though, that's why I posted this patch. > Have you tried setenv LC_CTYPE=en_US.ISO-8859-1 before starting > talk(1) and typing 8-bit chars? For most cases, this will work > for 8-bit chars. (Yes, it is _*BADLY*_ broken.) It unfortunately doesn't help here. > Sorry, the fact that you remove #include and the > check for LC_CTYPE makes this patch somewhat hard to accept. I can understand this. > However, I can accept a "talk-i18n" port that will go into the > ports temporarily until we fix isprint(). Would this be acceptable > for you? We can arrange to commit it as a port with you or I as > the maintainer. If you think it makes sense, I'd be glad to maintain such a port. Thanks, Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [hackers] Re: Setting memory allocators for library functions.
Tony Finch wrote: > Drew Eckhardt <[EMAIL PROTECTED]> wrote: > >In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > >>In most cases it is impossible to declare the data read-only because > >>it originally had to be read-write and you can't change its attributes > >>later. > > > >mprotect(2). > > If it's available at all, mprotect() is often limited to memory > obtained with mmap(), i.e. not malloc(). Not great for portability. FreeBSD malloc() calls mmap() as AFAIK many (if not all) malloc() implementations. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
talk(1) patch to allow 8bits characters
Hello,
talk(1) uses the isprint() function to determine if a character is
printable. If it's not, it outputs '^' followed by the character without
his 8th bit. However, isprint() and friends are broken currently on
FreeBSD (at least on -STABLE), so it will never recognize an accentued
character as printable.
The attached patch remove the isprint() test so that it's possible to
write special characters. It also removes the now useless setlocale()
call and headers.
When locale support will be complete, I'm volunteer to re-introduce
this check if someone thinks it's really worth it.
Could someone review this ?
Thanks,
Maxime
--
Don't be fooled by cheap finnish imitations ; BSD is the One True Code
Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6
Public Key : http://www.epita.fr/~henrio_m/
diff -cr talk/display.c /usr/src/usr.bin/talk/display.c
*** talk/display.c Tue Feb 27 20:35:30 2001
--- /usr/src/usr.bin/talk/display.c Tue Feb 27 20:39:02 2001
***
*** 44,50
* displaying of text
*/
#include "talk.h"
- #include
xwin_tmy_win;
xwin_this_win;
--- 44,49
***
*** 150,162
text++;
continue;
}
! if (!isprint((unsigned char)*text) && *text != '\t') {
! waddch(win->x_win, '^');
! getyx(win->x_win, win->x_line, win->x_col);
! cch = (*text & 63) + 64;
! waddch(win->x_win, cch);
! } else
! waddch(win->x_win, (unsigned char)*text);
getyx(win->x_win, win->x_line, win->x_col);
text++;
}
--- 149,155
text++;
continue;
}
! waddch(win->x_win, (unsigned char)*text);
getyx(win->x_win, win->x_line, win->x_col);
text++;
}
diff -cr talk/talk.c /usr/src/usr.bin/talk/talk.c
*** talk/talk.c Tue Feb 27 20:35:30 2001
--- /usr/src/usr.bin/talk/talk.cTue Feb 27 20:37:22 2001
***
*** 46,52
#endif /* not lint */
#include "talk.h"
- #include
/*
* talk: A visual form of write. Using sockets, a two way
--- 46,51
***
*** 70,77
int argc;
char *argv[];
{
- (void) setlocale(LC_CTYPE, "");
-
get_names(argc, argv);
check_writeable();
init_display();
--- 69,74
Re: soft updates and qmail (RE: qmail IO problems)
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Greg Black writes: > >Matt Dillon wrote: > > > >It seems to me that you're saying that softupdates is now the > >recommended way to go -- so why does 4.2-Release still have the > >dire warnings in /sys/ufs/ffs/README.softupdates? Is that file > >obsolete, or do the warnings still apply? > > I think that file is obsolete by now. > > I also think we should make newfs turn softupdates on by default in > -current. What do you think of what NetBSD implemented ? softupdates is now enabled via a mount option. This seems cleaner than the tunefs -n enable thing. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
fdescfs oddities
Hi, I run a 4.2-STABLE machine, world done this morning. I had some troubles with fdescfs. Reading the fdesc(5) manual page, I have to mount the fdescfs like I would mount procfs. But if I compile my kernel with options FDESC or if I load the fdesc.ko kernel module, I have access to /dev/fd/* and /dev/std* without mounting anything. Outdated documentation ? The real problem comes when I actually try to mount fdescfs. I was able to mount it several times on the same place (/dev) and 'mount' reported fdescfs as mounted several times. Just after this, my box locked up. I was able to switch to another virtual tty with alt+Fx but wasn't able to type anything nor to reboot with ctrl+alt+suppr. Cheers, Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kqueue()/kevent(), select() and poll()
Hi, I was wondering if it was reasonnable to implement the select() and poll() system calls as kqueue()/kevent() wrappers. This would make any application using these system calls benefit from the performance improvements of the new kernel thread. Do you think it's possible and that it won't cause some portability problems ? Best regards, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: misc freebsd-internal questions.
Marco van de Voort wrote: > (for the development of the Free Pascal compiler port): > > - Is there a way to easily check FreeBSD version (3.x or 4.x+, because of > the different syscallnrs for signal functions) on syscall level? > Use the sysctl kern.osreldate. > > - Can I use the assembler instruction ENTER ? E.g. Linux doesn't allow it, > because it would complicate the stack overflow handler? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Modification of the default configuration of sendmail request
Hi, A very useful feature of sendmail is not activated by default : genericstable. It does the opposite of what virtusertable do. The following lines should be appended to the freebsd.mc file : FEATURE(genericstable, `hash -o /etc/mail/genericstable')dnl GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')dnl Perhaps it would be nice to disallow VRFY and EXPN commands by default too. This can be easily done by adding goaway to the PrivacyOptions (and so put O PrivacyOptions=authwarnings,goaway). Hoping this will help. Regards, Maxime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 lockup side question ...
Hello, I would like to suggest you to use vim. It does syntax highlighting, auto-indenting of C code (and good indenting), it supports several windows, scripting, understand regular expressions, and finally, it's lightweight. It has useful macros for C like :make and it supports ctags to browse the source code easily. It even has a little GUI but it's done primarily for console, though. Maxime Henrion Clarence Brown wrote: > As you may know I'm bashing about trying to find > the point where my 486 based machine locks up > on a warm boot. I have been programming > embedded system for about 15 years using DOS > and later windows based tools. > > I am slowly going insane trying to use ee in one > window, and grep in another to find what I'm looking > for in the directory tree that holds the kernel source! > > OK, so I'm a whimp (I used to like the command line ;) > Is there any multi-file editor with an intuitive (read GUI) > interface I can run under KDE that provides multi-file > regular expression searching and stuff like that? I like to > view 2 files at the same time to look at declaration and > use at same time for instance. > > What do you guys use for your development > environment. I don't want a religious war, just some > pointers to hopefully intuitive and powerful programmer's > editors. Being out of my normal editing environment > where everything is now intuitive is like being pecked > at by a thousand worms... > > Thanks, Cla. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl from kernel
Thanks for your help ! If someone would be kind enough to answer them, I have a few other questions. I'm currently trying to modify sysctl_kern_proc() function in src/sys/kern/kern_proc.c But, to modify it, I must understand it first ;-) First, this sysctl is supposed to give the list of the running processes, but where this information is stored ? The function returns an int so it's probably not this :-) Second, what is an "oib" ? There are a lot of oib related stuff with sysctl and I can't understand what it is. Thanks for all future help. Maxime Henrion Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Maxime Henrion writes: > >Hi, > > > >I'm new to the FreeBSD kernel and I wanted to know what are the good > >methods to read a sysctl value from the kernel. Is it the same interface > >as in user-space ? > > > >Any help or links to some documentation would be greatly appreciated :) > > Look at the kernel_sysctl() function in src/sys/kern/kern_sysctl.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sysctl from kernel
Hi, I'm new to the FreeBSD kernel and I wanted to know what are the good methods to read a sysctl value from the kernel. Is it the same interface as in user-space ? Any help or links to some documentation would be greatly appreciated :) Thanks, Maxime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
limit processes that a user can 'see'
Hello, I have an idea that I would love to see applied in FreeBSD source code, but as I'm not skilled enough to code it, I post it to see if you think it makes sense, and if someone would be interested in coding this. It is a security measure regarding 'ps' command. By using the 'ps' command, any user logged in the system can view all the running processes, including root's one and processes of other users. My idea is to limit a bit this behaviour. Through a sysctl variable, the root could restrict the list of "readable" processes. By readable, I mean that it can be viewed. For example, a value of 0 could mean no restriction, 1 would hide root processes, 2 would restrict the visible processes to the processes owned by users in the same group as the current user, and finally, 3 would restrict the processes list to those owned by the current user (this is the way I'd have done it if I was able to). Of course, there would be no limitation for the superuser. The modification must be done at a low enough level so that a user won't be able to bypass this security measure by compiling another 'ps' so patching 'ps' doesn't suffise (in fact, if it was, I would have done it :-). What do you all think of this ? Best regards, Maxime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
config and config -r
The problem is that I _DID_ a make depend after the config -r, and this haven't prevent me to get a kernel which panic'ed. Larry Rosenman wrote: > config without the -r reminds you to run a make depend. > > Larry > > Warner Losh wrote: > > > > > In message <[EMAIL PROTECTED]> Maxime Henrion writes: > > > : But after rebooting on this new kernel, I had a page fault before > > > : any kernel message :/ Is there anything to check in order to know if I > > > : can use a config instead of a config -r ? If using a config without the > > > : -r option is dangerous, I think it shouldn't be the default. Is it the > > > : case ? > > > > > > Make depend is required if you ever want to build kernels more than > > > once. > > > > > > Warner > > > > Of course, I did a make depend ! > > I think that if config could be dangerous this way, -r should be its default > > behaviour. > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-stable" in the body of the message > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: config and config -r
Warner Losh wrote: > In message <[EMAIL PROTECTED]> Maxime Henrion writes: > : But after rebooting on this new kernel, I had a page fault before > : any kernel message :/ Is there anything to check in order to know if I > : can use a config instead of a config -r ? If using a config without the > : -r option is dangerous, I think it shouldn't be the default. Is it the > : case ? > > Make depend is required if you ever want to build kernels more than > once. > > Warner Of course, I did a make depend ! I think that if config could be dangerous this way, -r should be its default behaviour. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
config and config -r
Hello, I think the config program used to compile a kernel lacks some documentation because there are several points that remain unclear to me, even after reading the man page. I had several bad surprises with it ! :-) As I didn't want to recompile the whole stuff, I used a config and not a config -r to build a new kernel, after having changed its configuration. I removed several devices and I thought that won't cause any problem, as the objects files for these devices won't be linked into the kernel. But after rebooting on this new kernel, I had a page fault before any kernel message :/ Is there anything to check in order to know if I can use a config instead of a config -r ? If using a config without the -r option is dangerous, I think it shouldn't be the default. Is it the case ? Regards, -Maxime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ldconfig behaviour when no parameters are given
Hi,
Here is the small patch to activate the -R behaviour when no arguments
are given :) Thanks for helping me ! I'll work on the other modification
i suggested as soon as i have enough time.
Best regards,
- Maxime Henrion
*** /usr/src/sbin/ldconfig/ldconfig.c Sun Jan 16 22:08:58 2000
--- ldconfig.c Sun Jul 9 19:06:23 2000
***
*** 115,121
errx(1, "unknown object format \"%s\"", objformat);
hints_file = is_aout ? _PATH_LD_HINTS : _PATH_ELF_HINTS;
! while ((c = getopt(argc, argv, "Rf:mrsv")) != -1) {
switch (c) {
case 'R':
rescan = 1;
--- 115,123
errx(1, "unknown object format \"%s\"", objformat);
hints_file = is_aout ? _PATH_LD_HINTS : _PATH_ELF_HINTS;
! if (argc == 1)
! rescan = 1;
! else while((c = getopt(argc, argv, "Rf:mrsv")) != -1) {
switch (c) {
case 'R':
rescan = 1;
Re: ldconfig behaviour when no parameters are given
I'm a bit surprised to be the first person to reply to my own mail =) I want to suggest one more thing, I think it would be nice if ldconfig could check the persmissions on the directory when someone requests to add a new one. ldconfig should verify if the directory is owned by uid 0 and if the dir has not world write permission. Maxime Henrion wrote: > Hi everybody, > > When ldconfig is invoked without any parameters, the shared library > cache is reseted to the contents of /usr/lib only. I think such a > behaviour isn't very useful, especially when one knows that a lot of > people come to FreeBSD after having used Linux. The first time they get > an error message like "foo.so not found", they, nearly automatically, > run ldconfig and so screw up their shared library cache. > Is there a special reason why ldconfig behaves this way ? And is > there any application that rely on that behaviour ? This would at least > estonish me. That's why, i wanted to suggest that ldconfig prints a > usage screen when invoked without parameters, or else that it performs a > default and safe action, like a refresh (ldconfig -R). > > If it happens that what I say make sense, and that the two > requirements above are met (see the two questions), i'll be happy to > submit a patch. > > Waiting for your comments, > > - Maxiime Henrion > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ldconfig behaviour when no parameters are given
Hi everybody, When ldconfig is invoked without any parameters, the shared library cache is reseted to the contents of /usr/lib only. I think such a behaviour isn't very useful, especially when one knows that a lot of people come to FreeBSD after having used Linux. The first time they get an error message like "foo.so not found", they, nearly automatically, run ldconfig and so screw up their shared library cache. Is there a special reason why ldconfig behaves this way ? And is there any application that rely on that behaviour ? This would at least estonish me. That's why, i wanted to suggest that ldconfig prints a usage screen when invoked without parameters, or else that it performs a default and safe action, like a refresh (ldconfig -R). If it happens that what I say make sense, and that the two requirements above are met (see the two questions), i'll be happy to submit a patch. Waiting for your comments, - Maxiime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
why isnt there a ext2fs.ko ?
Hi guys,
I was wondering why the kernel module for ext2fs doesnt exist. I
think this will be very useful because a lot of linux users come to
FreeBSD and want to mount their existing linux partitions, and they have
to recompile their kernel. This isn't a hard task, but it's a bit
disappointing for new users.
- Maxime Henrion
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
