Re: rm -I patch (Re: Protection from the dreaded rm -fr /)
Here is the final commit I made to DFly. I cleaned up the confirmation message somewhat to make it more useful and correct the grammer. I'm not saying that this should or should not be done in FreeBSD, but I cannot think of any negatives and the -I option does allow for a far more sophisticated check then just '/' and a far less annoying confirmation then -i. http://www.dragonflybsd.org/cvsweb/src/bin/rm/rm.1.diff?r1=1.2r2=1.3f=u http://www.dragonflybsd.org/cvsweb/src/bin/rm/rm.c.diff?r1=1.3r2=1.4f=u http://www.dragonflybsd.org/cvsweb/src/etc/csh.cshrc.diff?r1=1.2r2=1.3f=u http://www.dragonflybsd.org/cvsweb/src/etc/profile.diff?r1=1.2r2=1.3f=u -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
attaching ugen(4) on multi interface USB devices
Hello everyone!, The last 1-2 days i've been trying to make some userspace OBEX utilities to work with a USB based Nokia GSM phone and doing this i discovered something that confuses me a little: The phone in question is Nokia 6230 and it has an USB interface. The phone has 11 interface descriptors, 2 of them are used for the Modem and CM over data. Judging from the windows drivers it seems that four of the other interfaces are OBEX compatible. But if i kldload umodem and plug the phone it detects only one ucom(4). and if i plug the phone without any u* modules loaded the kernel attaches ugen0 only. From what i understand it attaches the ugen0 using the info in the first interface descriptor in the device. Wouldn't it be more usefull for the kernel to attach ugen for every unknown interface in a device. For example when attaching the phone with umodem loaded, i will get the ucom(4) device and the other unrecognised interfaces will show up as ugens ? What do you think about that? P.S.: anyone know some good way to list the attached usb devices beyond usbdevs? It seems that the information that can be gathered from usbdevs is very limited. For example 'lsusb' in linux can show much more info. What do you think about that too? Thanks in advance for any info and/or flames :) --niki pgpVnYXvweLLA.pgp Description: PGP signature
help with porting from NetBSD
--[ Hello everyone, First of all sorry for my english... I need some help with porting kernel drivers from NetBSD to FreeBSD (usb irda driver for my Tekram dongle)... Can you help me with some docs, some kind of tutorials or faqs, or something else with this subject, please? Because i didn't find anything about it when googling... P.S. Please CC to me.. ---[]--- --[ Cool life for you, --[ bk.ru mailto:[EMAIL PROTECTED] ...::: Russian Saratov Linux User Group :::... ...::: FreeBSD - rulezzz :::... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: attaching ugen(4) on multi interface USB devices
On Wed, Oct 06, 2004 at 03:30:05PM +0300, Niki Denev wrote: Hello everyone!, The last 1-2 days i've been trying to make some userspace OBEX utilities to work with a USB based Nokia GSM phone and doing this i discovered something that confuses me a little: The phone in question is Nokia 6230 and it has an USB interface. The phone has 11 interface descriptors, 2 of them are used for the Modem and CM over data. Judging from the windows drivers it seems that four of the other interfaces are OBEX compatible. But if i kldload umodem and plug the phone it detects only one ucom(4). and if i plug the phone without any u* modules loaded the kernel attaches ugen0 only. From what i understand it attaches the ugen0 using the info in the first interface descriptor in the device. Wouldn't it be more usefull for the kernel to attach ugen for every unknown interface in a device. For example when attaching the phone with umodem loaded, i will get the ucom(4) device and the other unrecognised interfaces will show up as ugens ? What do you think about that? ugen attaches to the whole device and supporting all interfaces in one driver instance. If you already an interface driver atatched then ugen fails to attach the whole device. 11 interface descriptors sounds unlikely to be correct - it's more likely that some of them are alternative configurations and a device or interface can only be in a single configuration at a given time. You can switch between alternative configurations via ugen. I don't know about OBEX, but why don't you just create an interface class driver that attaches to OBEX interfaces - writing USB drivers is not very difficult if you know USB and a few kernel basics. P.S.: anyone know some good way to list the attached usb devices beyond usbdevs? It seems that the information that can be gathered from usbdevs is very limited. For example 'lsusb' in linux can show much more info. What do you think about that too? I like usbctl from NetBSDs usbutils. An older port draft is available under: http://www.cosmo-project.de/~bernd/usbutil.tgz It will also show you the interface configurations with all alternatives. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: attaching ugen(4) on multi interface USB devices
On Oct 06, Niki Denev wrote: The last 1-2 days i've been trying to make some userspace OBEX utilities to work with a USB based Nokia GSM phone and doing this i discovered something that confuses me a little: The phone in question is Nokia 6230 and it has an USB interface. The phone has 11 interface descriptors, 2 of them are used for the Modem and CM over data. Judging from the windows drivers it seems that four of the other interfaces are OBEX compatible. But if i kldload umodem and plug the phone it detects only one ucom(4). and if i plug the phone without any u* modules loaded the kernel attaches ugen0 only. From what i understand it attaches the ugen0 using the info in the first interface descriptor in the device. Wouldn't it be more usefull for the kernel to attach ugen for every unknown interface in a device. For example when attaching the phone with umodem loaded, i will get the ucom(4) device and the other unrecognised interfaces will show up as ugens ? What do you think about that? P.S.: anyone know some good way to list the attached usb devices beyond usbdevs? It seems that the information that can be gathered from usbdevs is very limited. For example 'lsusb' in linux can show much more info. What do you think about that too? Thanks in advance for any info and/or flames :) I seem to recall a problem with ugen that it doesn't discover endpoints on alt-interfaces. I've posted patches to this mailing list to work around the problem. --Mat -- Canada is a country whose main exports are hockey players and cold fronts. Our main imports are baseball players and acid rain. - Pierre Elliott Trudeau ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
syslog() reentrant when compiling with -pthread?
Hi I am a long time Unix developer but new with FreeBSD. I worked the last years mostly with OpenBSD. First I am overwhelmed by the number of mailing lists you guys provide. Second I am not sure if I picked the right one ;-) So please direct me to the right place if this list is only for discussion of FreeBSD system development... My question regarding thread-safeness of syslog(): On OpenBSD I used syslog_r() to do thread safe logging (the software in question is a sendmail milter, which runs multithreaded). FreeBSD does not have these functions, but the cc man page states that compiling with -pthread links in the thread safe libc_r library instead of libc. As syslog() seems to part of libc on FreeBSD, is it safe to assume that syslog() is indeed thread safe on FreeBSD when compiling with the -pthread switch? Thanks, Marc Balmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog() reentrant when compiling with -pthread?
In the last episode (Oct 06), Marc Balmer said: I am a long time Unix developer but new with FreeBSD. I worked the last years mostly with OpenBSD. First I am overwhelmed by the number of mailing lists you guys provide. Second I am not sure if I picked the right one ;-) So please direct me to the right place if this list is only for discussion of FreeBSD system development... My question regarding thread-safeness of syslog(): On OpenBSD I used syslog_r() to do thread safe logging (the software in question is a sendmail milter, which runs multithreaded). FreeBSD does not have these functions, but the cc man page states that compiling with -pthread links in the thread safe libc_r library instead of libc. As syslog() seems to part of libc on FreeBSD, is it safe to assume that syslog() is indeed thread safe on FreeBSD when compiling with the -pthread switch? The only unsafe part is openlog(), so set that up before you start any threads and you'll be okay. Once the log fd is opened, the syslog() call looks to be thread-safe. Everything in there is done with local variables and atomic writes. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog() reentrant when compiling with -pthread?
In the last episode (Oct 06), Dan Nelson said:
My question regarding thread-safeness of syslog(): On OpenBSD I
used syslog_r() to do thread safe logging (the software in question
is a sendmail milter, which runs multithreaded). FreeBSD does not
have these functions, but the cc man page states that compiling
with -pthread links in the thread safe libc_r library instead of
libc. As syslog() seems to part of libc on FreeBSD, is it safe to
assume that syslog() is indeed thread safe on FreeBSD when
compiling with the -pthread switch?
The only unsafe part is openlog(), so set that up before you start
any threads and you'll be okay. Once the log fd is opened, the
syslog() call looks to be thread-safe. Everything in there is done
with local variables and atomic writes.
I just noticed your email address :) smtp-vilter 1.1.5 works just
fine on FreeBSD with plain syslog with this port Makefile addition:
# Use regular syslog instead of openbsd's syslog_r interface.
post-patch:
@${FIND} ${WRKSRC} -name '*.[ch]' | ${XARGS} ${REINPLACE_CMD} \
-e 's/syslog_r(\(.*\), sdata,/syslog(\1,/' \
-e '/SYSLOG_DATA_INIT/d' \
-e 's/openlog_r(\(.*\),\(.*\),\(.*\),.*)/openlog(\1,\2,\3)/' \
-e 's/closelog_r(.*)/closelog()/'
FreeBSD should probably make syslog completely thread-safe, though.
Just adding a mutex around the open/close operations would be enough.
It looks like that's what Solaris does. The only place you really need
syslog_r afaik is if you want to open multiple log handles at different
facilities or levels at the same time.
--
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog() reentrant when compiling with -pthread?
For what it's worth, I've used syslog to the *console* before, in a multithreaded network daemon. No problems encountered. On Wed, 6 Oct 2004 16:28:32 +0200, Marc Balmer [EMAIL PROTECTED] wrote: Hi I am a long time Unix developer but new with FreeBSD. I worked the last years mostly with OpenBSD. First I am overwhelmed by the number of mailing lists you guys provide. Second I am not sure if I picked the right one ;-) So please direct me to the right place if this list is only for discussion of FreeBSD system development... My question regarding thread-safeness of syslog(): On OpenBSD I used syslog_r() to do thread safe logging (the software in question is a sendmail milter, which runs multithreaded). FreeBSD does not have these functions, but the cc man page states that compiling with -pthread links in the thread safe libc_r library instead of libc. As syslog() seems to part of libc on FreeBSD, is it safe to assume that syslog() is indeed thread safe on FreeBSD when compiling with the -pthread switch? Thanks, Marc Balmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog() reentrant when compiling with -pthread?
you probably want [EMAIL PROTECTED] Marc Balmer wrote: Hi I am a long time Unix developer but new with FreeBSD. I worked the last years mostly with OpenBSD. First I am overwhelmed by the number of mailing lists you guys provide. Second I am not sure if I picked the right one ;-) So please direct me to the right place if this list is only for discussion of FreeBSD system development... My question regarding thread-safeness of syslog(): On OpenBSD I used syslog_r() to do thread safe logging (the software in question is a sendmail milter, which runs multithreaded). FreeBSD does not have these functions, but the cc man page states that compiling with -pthread links in the thread safe libc_r library instead of libc. As syslog() seems to part of libc on FreeBSD, is it safe to assume that syslog() is indeed thread safe on FreeBSD when compiling with the -pthread switch? Thanks, Marc Balmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: attaching ugen(4) on multi interface USB devices
On Wed, Oct 06, 2004 at 09:48:49AM -0400, Mathew Kanner wrote: On Oct 06, Niki Denev wrote: The last 1-2 days i've been trying to make some userspace OBEX utilities to work with a USB based Nokia GSM phone and doing this i discovered something that confuses me a little: The phone in question is Nokia 6230 and it has an USB interface. The phone has 11 interface descriptors, 2 of them are used for the Modem and CM over data. Judging from the windows drivers it seems that four of the other interfaces are OBEX compatible. But if i kldload umodem and plug the phone it detects only one ucom(4). and if i plug the phone without any u* modules loaded the kernel attaches ugen0 only. From what i understand it attaches the ugen0 using the info in the first interface descriptor in the device. Wouldn't it be more usefull for the kernel to attach ugen for every unknown interface in a device. For example when attaching the phone with umodem loaded, i will get the ucom(4) device and the other unrecognised interfaces will show up as ugens ? What do you think about that? P.S.: anyone know some good way to list the attached usb devices beyond usbdevs? It seems that the information that can be gathered from usbdevs is very limited. For example 'lsusb' in linux can show much more info. What do you think about that too? Thanks in advance for any info and/or flames :) I seem to recall a problem with ugen that it doesn't discover endpoints on alt-interfaces. I've posted patches to this mailing list to work around the problem. It doesn't work when you call USB_SET_ALTINTERFACE then USB_SET_CONFIG? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Where to start for someone new to kernel coding
Hi, I am on this list so there is no need to cc me. I want to extend the disk quota system: - Implement a user space daemon to control it. - Pass control from the kernel to the user space daemon. By doing this, you can have much finer grained control over disk quota's, such as controling directories for users as opposed to file systems, setting quotas on what files reside in a directory as opposed to by UID etc. Is this at all possible, and if so, where should I start looking for coding with the kernel. I already have a fair experience in coding with C. -John -- /~\ The ASCII ASCII stupid question, get a EBCDIC ANSI. \ / Ribbon Campaign John Oxley X Against HTMLhttp://oxo.rucus.net/ / \ Email! oxo at rucus.net Personally, I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT. -- Thomas Scoville ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Wednesday 06 October 2004 02:31, Matthew Dillon wrote: The university I used to work for had something like it and it got 99% of the cases Yow. 78 messages and counting. Er, 79 now. I'll bet poor Giorgos wishes he never started this thread! Get ready. get set DIVE! A good friend of mine has, for at least the last two decades, used something along the lines of: if ( $?prompt ) then alias rm 'mv \!* $HOME/misc/trash' endif However, it seems that the correct solution is to create a new option, -I, which puts rm into 'idiot user mode' and has all the desired confirmation effects listed in this thread and none of the undesired effects such as -i returns. Then if anyone wants to use it they can just create an alias similar to the above for -I and poof, problem solved. It's fairly easy to detect '*' and ask for confirmation, and also easy to ask for a single confirmation on a directory (not ask again for any recursion). Then you guys can argue over whether the alias should appear in the system-wide default csh.cshrc and friends, rather then argue over the destruction of rm's basic nature. I will only point out that 'rm' is used fairly universally in scripts and there are obviously things other then '/' that you would want to ask confirmation for that just as obviously cannot be made default operation for rm. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Printing from kernel
Hi, I have some problems with printing from kernel. At first I think that my problems was cause I use printf, but changed all of them to log cause it safe to use from interrupt handlers. The situation become better but I still observe system lockup in case I output some debug information from my driver. Also I have some problems with system console via com port. Instead of messages from kernel I see the first letter of the month name. Could anybody comment my observation? Does anybody saw anything like this? Oh, I forget to say I observe that with both Current and Releng5, SMP. Also I can't trigger NMI so I can't see the point of lockup. rik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Printing from kernel
On 7 Oct, Roman Kurakin wrote: Hi, I have some problems with printing from kernel. At first I think that my problems was cause I use printf, but changed all of them to log cause it safe to use from interrupt handlers. The situation become better but I still observe system lockup in case I output some debug information from my driver. Also I have some problems with system console via com port. Instead of messages from kernel I see the first letter of the month name. This is a bug in syslogd related to non-blocking I/O that bde and I discussed quite a while back, though we never figured out a proper fix. I recently made the interesting discovery that the same problem isn't present on sparc64. I think it'll start working again if you restart syslogd. Could anybody comment my observation? Does anybody saw anything like this? Oh, I forget to say I observe that with both Current and Releng5, SMP. Also I can't trigger NMI so I can't see the point of lockup. I generally use printf for this sort of thing, and I was going to suggest that you take a look at the KTR stuff, but that won't help if the machine totally locks up so that you can't get to the KTR buffer. I think you'll have trouble getting close to the bug if you use log because of the log latency from the generation of the message, passing it through syslogd, and back to the kernel to be printed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Printing from kernel
On Thursday, 7 October 2004 at 0:31:33 +0400, Roman Kurakin wrote: Hi, I have some problems with printing from kernel. At first I think that my problems was cause I use printf, but changed all of them to log cause it safe to use from interrupt handlers. The situation become better but I still observe system lockup in case I output some debug information from my driver. About the only thing I can think is that you're doing this in some area where it's unsafe to print, probably holding a lock that's needed in the print routines. Also I have some problems with system console via com port. Instead of messages from kernel I see the first letter of the month name. Could anybody comment my observation? Without more detail, it's impossible to help. Does anybody saw anything like this? No. printf() is widely used in the kernel. Oh, I forget to say I observe that with both Current and Releng5, SMP. Also I can't trigger NMI so I can't see the point of lockup. Take a look at your code and check what locks you're holding. Also, if this is only for debugging, you should be using the kernel debugger. Greg -- See complete headers for address and phone numbers. pgpYJ4Myqltru.pgp Description: PGP signature
Re: syslog() reentrant when compiling with -pthread?
Am 06.10.2004 um 16:48 schrieb Dan Nelson: The only unsafe part is openlog(), so set that up before you start any threads and you'll be okay. Once the log fd is opened, the syslog() call looks to be thread-safe. Everything in there is done with local variables and atomic writes. At least on OpenBSD I can use %m in the syslog() format string. This results in a call to strerror(), which is not thread safe, AFAIK. This probably is true for FreeBSD as well, so we have the following three conditions for thread safe syslog(): 1) openlog() must be called before any threads that use syslog() are started. 2) The first argument to openlog() must not be NULL. 3) The %m Format String must not be used in syslog() calls. Any comments? - Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog() reentrant when compiling with -pthread?
In the last episode (Oct 07), Marc Balmer said: At least on OpenBSD I can use %m in the syslog() format string. This results in a call to strerror(), which is not thread safe, AFAIK. This probably is true for FreeBSD as well, so we have the following three conditions for thread safe syslog(): 1) openlog() must be called before any threads that use syslog() are started. 2) The first argument to openlog() must not be NULL. 3) The %m Format String must not be used in syslog() calls. 4) make syslog() use strerror_r() Actually, for known errno values, strerror() is thread-safe on FreeBSD. It just returns a pointer into sys_errlist[]. For invalid values it stuffs Unknown error: ## into a static buffer and returns a pointer to that. I'll update the PR to make syslog call strerror_r(). http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/72394 -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
