RE: await asleep
The functions await() and asleep() in kern_synch.c
are marked as EXPERIMENTAL/UNTESTED.
Is this comment still valid? Does anyone have used
those functions successfully? Should I better not
use them in my device driver code for RELENG_4?
How do I correctly cancel a request (as I should do
according to the man page): asleep (NULL, 0, NULL, 0)?
The await family was removed in 5.x and beyond, so trying to
use them in 4.x will make your driver very unportable. There
are better ways than await to handle delayed events.
Ok, my [classical] situation is this:
1. an interrupt handler writes into a queue
2. a read function reading from the queue
pseudo code using asleep()/await() (no error handling):
read()
{
forever {
while ! empty_queue() {
uiomove(uio, ...);
if (uio-uio_resid == 0) {
return 0;
}
}
asleep( read_queue, ...);
if (empty_queue ()) {
error = await (...);
} else {
asleep (NULL, ...);
}
}
}
If I want to do that with plain tsleep() I
have to use spl??() to lock the empty_queue() call
and not lose a wakeup() from the interrupt handler.
But if I add error checks the code becomes very ugly
compared to the solution above.
I never wrote a driver under 5.X. As I understand
I would use a mutex to access the queue and call msleep()
to sleep with the mutex unlocked. (That seems to simulate
pthread_cond_timedwait(), doesn't it?)
pseudo code:
read()
{
forever {
while ! empty_queue() {
uiomove(uio, ...);
if (uio-uio_resid == 0) {
return 0;
}
}
mtx_lock (mutex);
if (empty_queue ()) {
error = msleep (queue, mutex, ...);
};
mtx_unlock (mutex);
}
}
How would you suggest to do that under 4.X
in an _elegant_ way w/o asleep/await?
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD ported to the XBox!
Rink Springer [EMAIL PROTECTED] writes: Hello everyone, Over the last 2 weeks, I have been working on a port of FreeBSD for the XBox. During this effort, Ed Schouten has given me assistance by reviewing patches and giving advice. Great, thanks for your work. I got my XBOX with an Aladdin modchip. Today I downloaded the LiveCD and tried to boot from it, but failed. (I don't have the Cromwell BIOS installed on my XBOX ). Then I booted XBOX with GentooX install CD (Home edition), and replaced GentooX CD with FreeBSD XBOX live CD after it booted into GentooX Loader, selected CD option, then the XBOX was try to boot from it, I can see there's four choices (FreeBSD 5.4 ... CD/HDD, FreeBSD 6.0-BETA1 ... CD/HDD). I tried all of them, it just stopped there, it didn't show any FreeBSD boot messages. Thank you for portting FreeBSD to XBOX. XD Regards, loader ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using -ftracer stops buildworld at shutdown.c
On Tue, Jul 26, 2005 at 06:46:55PM -0400, jason henson wrote:
To avoid this warning, the variables and/or arguments should be
prevented from being optimized by declaring them as volatile.
So I sprinkled some volatiles around, but mostly got more errors that
said gcc volatile discards qualifiers from pointer target type in the
fprintf functions.
Replacing line 276 with 'FILE *volatile pf;' fixes the warning. But the
usage of {long,set}jmp() is wrong anyway since timeout() can jump back
into timewarn() while that isn't executed at all.
Stefan
Index: shutdown.c
===
RCS file: /home/ncvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.28
diff -I.svn -u -r1.28 shutdown.c
--- shutdown.c 25 Jan 2005 08:40:51 - 1.28
+++ shutdown.c 27 Jul 2005 13:24:29 -
@@ -273,7 +273,7 @@
{
static int first;
static char hostname[MAXHOSTNAMELEN + 1];
- FILE *pf;
+ FILE *volatile pf;
char wcmd[MAXPATHLEN + 4];
if (!first++)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with pic16l_setled
Hi Ludvig, * Ludvig Strigeus ([EMAIL PROTECTED]) wrote: Hi! I see this code: +ENTRY(pic16l_setled) + push%ebp + mov %esp,%ebp + + movl0x8(%ebp),%ebx + orl $0x800,%ebx + callpic16l_ledhlp + movl$0x701,%ebx + callpic16l_ledhlp + + leave + ret With the standard x86 calling convention, you're not supposed to modify ebx, esi or edi without saving them first. Try adding a push/pop ebx around. I doubt this is the problem (I've looked at other .s files like i386/i386/support.s, function ssdtosd, and they don't seem to do this). You see, in C, I call the function like this (for example): void pic16l_setled(unsigned int val); pic16l_setled (0x1234); And it gets assembled to: pushl $0x1234 callpic16l_setled But it should be assembled to: pushl $0x1234 callpic16l_setled add $4,%esp /* ditch the parameter */ I don't know why it doesn't do this :( +ENTRY(pic16l_reboot) + pushl $0x01 + pushl $0x02 + pushl $0x20 + callpic16l_setbyte + ret You're forgetting to adjust the stack here.. you should add 12 to esp before returning. Same thing in pic16l_poweroff. Indeed, very correct! Since there functions plainly reboot / halt, I never noticed this, but you are indeed correct. I'll fix it in a new patchset. I've never done any FBSD dev, so i could be wrong...but it's worth a try. Thank you very much for your time! I've CC-ed this discussion to hackers@, perhaps someone knows more about this ? -- Rink P.W. Springer- http://rink.nu God, root, what is difference? - Pitr, Userfriendly pgpmWbbPdcmdS.pgp Description: PGP signature
RE: Problem with pic16l_setled
You see, in C, I call the function like this (for example): void pic16l_setled(unsigned int val); pic16l_setled (0x1234); And it gets assembled to: pushl $0x1234 callpic16l_setled But it should be assembled to: pushl $0x1234 callpic16l_setled add $4,%esp /* ditch the parameter */ Usually gcc collects stack cleanups. See -fno-defer-pop. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: await asleep
On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
Daniel Eischen wrote: On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
On Wed, 27 Jul 2005, Scott Long wrote: Daniel Eischen wrote: On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, and the priority argument of tsleep() doesn't have any meaning any longer, right? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
Daniel Eischen wrote: On Wed, 27 Jul 2005, Scott Long wrote: Daniel Eischen wrote: On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, Incorrect. A mutex is not a replacement for sleep. CV's and semaphores implement some of what tsleep does, but tsleep is absolutely appropriate when you want to sleep for an event (like disk i/o completing) and don't need to worry about mutexes. Not every inch of the kernel needs to be covered by mutexes, Giant or otherwise. and the priority argument of tsleep() doesn't have any meaning any longer, right? I thought it did, but John can give the definitive answer. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
On Wed, 27 Jul 2005, Scott Long wrote: Daniel Eischen wrote: My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, Incorrect. A mutex is not a replacement for sleep. CV's and semaphores implement some of what tsleep does, but tsleep is absolutely appropriate when you want to sleep for an event (like disk i/o completing) and don't need to worry about mutexes. Not every inch of the kernel needs to be covered by mutexes, Giant or otherwise. Traditionally, you did splXXX() then tsleep(). But splXXX() has been deprecated and you need to use mutexes for protection. If you are going to sleep for an event, that is cv_wait() and friends and you use the mutex for protection. It's hard to imagine that queueing disk I/O requests and their completions don't need mutexes (or lockmgr?) for protection, but I'll take your word for it. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
On 7/26/05, David Malone [EMAIL PROTECTED] wrote: That's correct, but it probably takes a few microseconds for the carries sense to kick in (if there wasn't a delay there would be almost no need for the random backoff). That's why you'll also have to have your transmissions synchronised very closely. David. Since my project is running in adhoc mode, I noticed that there is a LOT of noise being generated by the two machines I want to use in order to generate a collision. The noise is the adhoc beacon being broadcast. Clearly they need to talk to each other, but I'd really like to quiet down the channel so I can attempt this collision. I found this in if_ath: /* NB: the beacon interval is kept internally in TU's */ and this in /sys/contrib/dev/ath/ah_desc.h HAL_TX_QUEUE_BEACON = 2,/* beacon xmit q */ HAL_TX_QUEUE_CAB= 3,/* crap after beacon xmit q */ and... # cat ah.h | grep interval * beacon interval (given in TU's) can also include flags u_int32_t bs_intval; /* beacon interval+flags */ #define HAL_BEACON_PERIOD 0x /* beacon interval period */ I think the carrier sensing is kicking in because the channel is not quiet due to the beacons. Do the tx q things matter? seems like the hal_beacon_period would be the most important line, but I don't see how that flag (if it is one) can be used. -Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ProPolice symbols in libc or libssp ?
Hi,
Being full of enthusiasm, I checked if by chance libraries could have
dynamic object dependencies. It appears this is not the case, but
since I'm neither a GCC nor binutils hacker, maybe there is a way to
achieve this. This is the purpose of this email ?
What you have been smoking? Dynamic libraries surely can depend on other
objects :-) Just link libc with -lssp, given that libssp should be
self-contained or any other library you want to have propolice in
against ssp. Static libraries are not an issue either, since you can
simply add the object file. If you look around, you might even find some
programs which allow you to add the dependency into an existing library,
which would be perfect for libc.
(Sorry, you guys are maybe fed up with ProPolice and I'm sending a huge
mail again, but I have three questions. Nevertheless, I would be glad
if someone with some bigger experience could take some time to answer
them.)
Eheh, I've not been smoking anything, maybe should I. ;-)
1)
In fact I've been misleaded because I modified the GCC configuration
(FBSD_LIB_SPEC in contrib/gcc/config/freebsd-spec.h) to make it
automatically link against libssp and I supposed wrongly this would
link programs _and_ libraries with libssp. When buildworld was
completed, I checked this with ldd(1), that's why I thought it wasn't
possible to have libraries depending on other objects (installworld not
done that's why libssp is not resolved) :
%%%
jarjarbinks# ldd /usr/obj/usr/src/bin/cat/cat
/usr/obj/usr/src/bin/cat/cat:
libssp.so.1 = not found (0x0)
libc.so.6 = /lib/libc.so.6 (0x3137b000)
jarjarbinks# ldd /usr/obj/usr/src/lib/libz/libz.so.3
/usr/obj/usr/src/lib/libz/libz.so.3:
%%%
It seems that LIB_SPEC macro content is used only when linking programs,
not libraries, although the GCC Internals book states that it is used
whenever the linker is used [1]. I can understand that each library
should not be linked against libc, and that's why ld(1) isn't called
with LIB_SPEC macro when linking shared libraries. But how should I do
to have shared libraries linked against libssp ? Use LDADD make
variable (see question 2) ?
2)
Secondly, after digging a bit more, I thought that I could replace the
GCC's freebsd-spec.h hack by using the LDADD make variable. The
advantage is that it will make import of next GCC release easier.
Furthermore, it would make me sure that libraries are really linked with
libssp (see question 1). The drawback is that this will be a mess
for ports to handle this because their tree is used through numerous
FreeBSD major branches : this would require to test that
${CC} ${CFLAGS} actually handles stack protector and add -lssp
depending on the result. Additionaly, I would say that only GCC is able
to really know when it is needed to link against libssp or not, since
the make system will either have a weak assumption of this or need some
black magic as described above for ports.
3)
Finally, my libssp requires libc because I use sysctl(3), syslog(3) and
a few other functions. I resolved the problem of circular dependancies
with weak dependancies : libc includes libssp source file but with
different symbol names to avoid conflicts. Then I create weak references
for the real SSP symbols names (see attached patch for an illustration).
OTOH, while I was documenting on GCC, I saw they use something like
-lgcc -lc -lgcc (see macro LINK_GCC_C_SEQUENCE_SPEC from [1]). Is it
something possible for libssp, or is it simply a hack that should be
avoided ?
If you are still reading at this point, thanks :-).
I hope to not have forgotten anything or I will need to post again :).
Regards,
[1] http://gcc.gnu.org/onlinedocs/gccint/Driver.html
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
Index: lib/Makefile
===
RCS file: /nfs/obiwan/cvs/src/lib/Makefile,v
retrieving revision 1.206
diff -u -p -u -p -r1.206 Makefile
--- lib/Makefile14 Jul 2005 17:59:50 - 1.206
+++ lib/Makefile26 Jul 2005 16:41:42 -
@@ -32,8 +32,8 @@ SUBDIR= ${_csu} libcom_err libcrypt libk
libipx libkiconv libmagic libmemstat libmenu ${_libmilter} ${_libmp} \
${_libncp} ${_libngatm} libopie libpam libpanel libpcap \
libpmc ${_libpthread} ${_libsdp} ${_libsm} ${_libsmb} ${_libsmdb} \
- ${_libsmutil} libstand libtelnet ${_libthr} ${_libthread_db} libufs \
- libugidfw ${_libusbhid} ${_libvgl} libwrap liby libz ${_bind}
+ ${_libsmutil} libssp libstand libtelnet ${_libthr} ${_libthread_db} \
+ libufs libugidfw ${_libusbhid} ${_libvgl} libwrap liby libz ${_bind}
.if exists(${.CURDIR}/csu/${MACHINE_ARCH}-elf)
_csu=csu/${MACHINE_ARCH}-elf
Index: lib/libc/sys/Makefile.inc
===
RCS file: /nfs/obiwan/cvs/src/lib/libc/sys/Makefile.inc,v
retrieving revision 1.113
diff
file locking
Hello hackers, man page for flock(2) and fcntl(2) reads that a system call returns EOPNOTSUPP if file descriptor refers to an object that does not support file locking. However, it seems that it is not always true. For example, if underlying object is a device or a fifo returned error code depends on type of lock. When I look at sources of VOP_ADVLOCK for fifo (sys/fs/fifofs/fifo_vnops.c, fifo_advlock() function) I see the following line: ... return (ap-a_flags F_FLOCK ? EOPNOTSUPP : EINVAL); ... I.e. for freebsd locks EOPNOTSUPP error code is returned. It is correct. But for posix locks EINVAL error code is returned. Is it correct? Thanks you in advance, Sergey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : and the priority argument of tsleep() doesn't have any meaning : any longer, right? : : : I thought it did, but John can give the definitive answer. Priority is still useful. It is the same priority that msleep uses. tsleep is completely equivalent to msleep with a null mtx parameter. The priority field is indeed used: /* * Adjust this thread's priority. */ mtx_lock_spin(sched_lock); sched_prio(td, priority PRIMASK); mtx_unlock_spin(sched_lock); msleep is a different primitive that cv_wait and friends. cv_wait enforces good mutex practices and generally should be used... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
