Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Nope, just a sysctl. I guess then you just need a sysctl which lets you read the rules for a given devfs mount point and another which lets you set the rules for a given defvs mount point. I don't know if we also need a global ruleset which is applied if the mount point speficic rules fail to match. The rules should be able to chmod and chown the nodes. Should it also be able to prevent the creation matching nodes also? You mentioned matching on the names drivers and nodes. Are there any other sorts of matching we are likely to need? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], David Malone writes: On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Nope, just a sysctl. I guess then you just need a sysctl which lets you read the rules for a given devfs mount point and another which lets you set the rules for a given defvs mount point. I don't know if we also need a global ruleset which is applied if the mount point speficic rules fail to match. True, forgot that. In that case lets make them a mount option using mux@ new nmount(2) systemcall. The rules should be able to chmod and chown the nodes. Should it also be able to prevent the creation matching nodes also? Yes. You mentioned matching on the names drivers and nodes. Are there any other sorts of matching we are likely to need? Ideally I would want to match on names, driver names and types, ie: name==ttyd0, driver==sio and type==tty, but I think the important thing here is to make it exensible in the future. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
simplelock to lock_class?
Hi, eveyone, I found the FreeBSD4.x defined the simplelock in the sys/sys/lock.h. But, it doesn't exist in FreeBSD5.0, why? If I want use the FreeBSD4.x simplelock function, how and what can I use in FreeBSD5.0? Thank you! Best Regards, Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
[no subject]
subscribe [EMAIL PROTECTED] = To be poor is hard, but to be a poor race in a land of dollars is the very bottom of hardships. --W.E.B. DuBois __ Do You Yahoo!? Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
:In message: [EMAIL PROTECTED]
:Philip M. Gollucci [EMAIL PROTECTED] writes:
:: cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall
:: -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c
:: /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups
:: within expressions
:: cc: Internal compiler error: program cc1 got fatal signal 11
:
:Looks like the C compiler really didn't like the braced-groups within
:expressions.
:
:#define get_rtld_cleanup() \
:({ fptr __value; \
: __asm__(movl %%edx,%0 : =rm(__value)); \
: __value; })
:...
:rtld_cleanup = get_rtld_cleanup();
:yet both of these parts of this file hasn't been changed since 1998!
:
:appears to be the real reason since this file is compiled -ansi
:-pedantic. And it would appear on the surface to still be a problem.
:However, it looks like my version isn't compiling it -ansi -pedantic:
:
:cc -O -pipe -elf -Wall -fkeep-inline-functions
:-I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o
:gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c
:
:So something really strange is going on, but I'm not sure what.
:
:Warner
I always like to say that these things are Illegal everywhere except
in GCC on a sunny Sunday.
This is a misfeature in GCC. Like dynamically sized arrays declared
on the stack (which to my horror I actually use sometimes) or dynamic
braced auto initializers (which I don't).
It would be best to cleanup instances of these when we come across them.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
blockable sleep panic on Alpha / current
During a make release I just got a panic. The build progressed until: gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 imaxabs.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 imaxdiv.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 labs.3.gz The running system is a -current as of today. The panic: login: FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x7,a0=0x6 db db trace Debugger() at Debugger+0x34 panic() at panic+0x188 witness_lock() at witness_lock+0xb4 _mtx_lock_flags() at _mtx_lock_flags+0xd8 trap() at trap+0x4c8 XentMM() at XentMM+0x2c --- memory management fault (from ipl 7) --- statclock_process() at statclock_process+0x1d4 statclock() at statclock+0x78 alpha_clock_interrupt() at alpha_clock_interrupt+0xac interrupt() at interrupt+0xb8 XentInt() at XentInt+0x28 --- interrupt (from ipl 4) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 witness_lock() at witness_lock+0x408 _mtx_lock_flags() at _mtx_lock_flags+0xd8 lockmgr() at lockmgr+0x70 vm_map_lock_read() at vm_map_lock_read+0x28 vm_map_lookup() at vm_map_lookup+0x78 vm_fault1() at vm_fault1+0xa8 vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- ithread_schedule() at ithread_schedule+0xa4 alpha_dispatch_intr() at alpha_dispatch_intr+0x130 interrupt() at interrupt+0x138 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 vm_fault1() at vm_fault1+0x110c vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- pmap_enter_quick() at pmap_enter_quick+0x1d4 pmap_object_init_pt() at pmap_object_init_pt+0x1a4 vm_map_insert() at vm_map_insert+0x35c elf_load_section() at elf_load_section+0x190 exec_elf_imgact() at exec_elf_imgact+0x278 execve() at execve+0x324 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (59, FreeBSD ELF, execve) --- --- user mode --- db -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
Julian, thank you very much for a such detailed answer :) [...] I hope that this helps you! yes it did help :) i changed my code and it seems to work just fine. i wish i had SMP laptop to test it :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: Julian, thank you very much for a such detailed answer :) [...] I hope that this helps you! yes it did help :) i changed my code and it seems to work just fine. i wish i had SMP laptop to test it :) Well it aint exactly SMP safe YET, until I make those changes through teh REST of the system. There are still direct timeout() calls in several modules that I need to change to follow my own suggestions and there are many nodes that need to be changed to gain a lock when they first try insert data into the graph. e.g. ng_tty, ng_ether, (actually those two always do queueing but there are others..) I need to sit down with Archie and go through the nodes with an eye to locking. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
Matthew Dillon wrote: I always like to say that these things are Illegal everywhere except in GCC on a sunny Sunday. This is a misfeature in GCC. Like dynamically sized arrays declared on the stack (which to my horror I actually use sometimes) or dynamic braced auto initializers (which I don't). It would be best to cleanup instances of these when we come across them. Don't forget the varradic macros with the ... in their parameter lists. Since this original thread started because some poor fool was using Flexilint, probably in the vain hope that code that lints clean is somehow immune to logic errors (this is where I've seen Flexolint used in the past), it should be noted that there is no dead chicken you can wave over the options to make varradic macros legal... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc -O broken in CURRENT
Hi all, Unfortunatly I have a example from the ports, needed by OpenOffice port (work in progress) cd /usr/ports/devel/stlport/ make install cd /usr/ports/devel/stlport/work/STLport-4.5.3/test/eh gmake -f gcc-freebsd.mak [vector] :testing n-size constructor (const) ... 95 try successful [vector] :testing pointer range constructor (const) ... Bus error - core dumped Then remove the three -O from gcc-freebsd.mak and run it again. You will see that all tests are successfully done. [...] [hash_multiset] :testing default constructor (const) ... 2 try successful [hash_multiset] :testing iterator range n-size constructor (const) ... 127 try successful [hash_multiset] :testing copy constructor (const) ... 54 try successful [hash_multiset] :testing assignment operator (weak) ... 53 try successful [...] [string] :testing copy constructor (const) ... 2 try successful [string] :testing assignment operator (weak) ... 1 try successful EH test : Done Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
Julian, [...] I hope that this helps you! yes it did help :) i changed my code and it seems to work just fine. i wish i had SMP laptop to test it :) Well it aint exactly SMP safe YET, until I make those changes through teh REST of the system. There are still direct timeout() calls in several modules that I need to change to follow my own suggestions and there are many nodes that need to be changed to gain a lock when they first try insert data into the graph. e.g. ng_tty, ng_ether, speaking of ng_tty... it is clear to me how to inject data into Netgraph in a safe way, but it is not yet clear how Netgraph can inject data into other subsystems. you see, the Bluetooth spec defines several Host (PC) to Host Controller (Bluetooth unit) communication protocols. one of them is UART transport layer (AKA H4). i have implemented H4 line discipline that also a Netgraph node. (i called it ng_sio in my report but it was wrong). it works now, and i can talk to Xircom card, but it should be changed later. any hints? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: Julian, [...] speaking of ng_tty... it is clear to me how to inject data into Netgraph in a safe way, but it is not yet clear how Netgraph can inject data into other subsystems. you see, the Bluetooth spec defines several Host (PC) to Host Controller (Bluetooth unit) communication protocols. one of them is UART transport layer (AKA H4). i have implemented H4 line discipline that also a Netgraph node. (i called it ng_sio in my report but it was wrong). it works now, and i can talk to Xircom card, but it should be changed later. any hints? Netgraph will have to aquire whatever lock is required for that module. Most subsystems have no locks yet so it's a bit early to say how it will work :-) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep panic on Alpha / current
On Mon, Mar 04, 2002 at 07:13:03PM +0100, Wilko Bulte wrote: Another one, appears to be identical. No dump, no kernel debugger unfortunately. The kernel has WITNESS enabled too. I'll try to catch a dump if that is helpful to someone? Wilko FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va= 0x60 type = access violation cause = load instructon pc = 0xfc50b220 ra = 0xfc50b218 sp = 0xfe000e22c450 usp= 0x11fff0a8 curthread = 0xfe000e107d00 pid = 44138, comm = cc Stopped at fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va= 0x60 type = access violation cause = load instructon pc = 0xfc50b220 ra = 0xfc50b218 sp = 0xfe000e22b9c8 usp= 0x11fff0a8 curthread = 0xfe000e107d00 pid = 44138, comm = cc Stopped at fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va= 0x60 type = access violation cause = load instructon pc = 0xfc50b220 ra = 0xfc50b218 sp = 0xfe000e22af40 usp= 0x11fff0a8 curthread = 0xfe000e107d00 pid = 44138, comm = cc Stopped at halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc4231ec During a make release I just got a panic. The build progressed until: gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 imaxabs.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 imaxdiv.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 labs.3.gz The running system is a -current as of today. The panic: login: FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x7,a0=0x6 db db trace Debugger() at Debugger+0x34 panic() at panic+0x188 witness_lock() at witness_lock+0xb4 _mtx_lock_flags() at _mtx_lock_flags+0xd8 trap() at trap+0x4c8 XentMM() at XentMM+0x2c --- memory management fault (from ipl 7) --- statclock_process() at statclock_process+0x1d4 statclock() at statclock+0x78 alpha_clock_interrupt() at alpha_clock_interrupt+0xac interrupt() at interrupt+0xb8 XentInt() at XentInt+0x28 --- interrupt (from ipl 4) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 witness_lock() at witness_lock+0x408 _mtx_lock_flags() at _mtx_lock_flags+0xd8 lockmgr() at lockmgr+0x70 vm_map_lock_read() at vm_map_lock_read+0x28 vm_map_lookup() at vm_map_lookup+0x78 vm_fault1() at vm_fault1+0xa8 vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- ithread_schedule() at ithread_schedule+0xa4 alpha_dispatch_intr() at alpha_dispatch_intr+0x130 interrupt() at interrupt+0x138 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 vm_fault1() at vm_fault1+0x110c vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- pmap_enter_quick() at pmap_enter_quick+0x1d4 pmap_object_init_pt() at pmap_object_init_pt+0x1a4 vm_map_insert() at vm_map_insert+0x35c elf_load_section() at elf_load_section+0x190 exec_elf_imgact() at exec_elf_imgact+0x278 execve() at execve+0x324 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (59, FreeBSD ELF, execve) --- --- user mode --- db -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ---end of quoted text--- -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
