Re: Where is pci_intr_establish() & _thread_sys_read()?
On Monday, March 06, 2000, Zhihui Zhang wrote: > Can anyone tell me where is the code for pci_intr_establish() and > _thread_sys_read()? I could not find them under /usr/src. I can tell you offhand that _thread_sys_anything is the _real_ syscall for `anything'. This is because a lot of syscalls are reimplemented within libc_r for reasons that are kind of obvious (directly calling the read syscall from one thread would block all the other threads in a process). So _thread_sys_open() == open(2), _thread_sys_read() == read(2), etc. I don't know about pci_intr_establish. -- |Chris Costello <[EMAIL PROTECTED]> |Today's assembler command : EXOP Execute Operator ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where is pci_intr_establish() & _thread_sys_read()?
On Mon, 6 Mar 2000, Chris Costello wrote: >On Monday, March 06, 2000, Zhihui Zhang wrote: >> Can anyone tell me where is the code for pci_intr_establish() and >> _thread_sys_read()? I could not find them under /usr/src. > > I can tell you offhand that _thread_sys_anything is the _real_ >syscall for `anything'. This is because a lot of syscalls are >reimplemented within libc_r for reasons that are kind of obvious >(directly calling the read syscall from one thread would block >all the other threads in a process). So _thread_sys_open() == >open(2), _thread_sys_read() == read(2), etc. > > I don't know about pci_intr_establish. > >-- >|Chris Costello <[EMAIL PROTECTED]> >|Today's assembler command : EXOP Execute Operator >` > pci_intr_establish is not part of FreeBSD's interface(s), as far as I know. This probably belongs to either NetBSD or OpenBSD (since the drivers that use this routine to setup an interrupt use it under #if defined(__OpenBSD__) or __NetBSD__ blocks. See our bus interface code (e.g. bus_if.[ch]) --Bosko .. Bosko Milekic * [EMAIL PROTECTED] * http://pages.infinit.net/bmilekic/ Montreal, Quebec, Canada. * Technokratis: http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
Daniel Eischen wrote: > > Some of the man pages and cancellation support came from OpenBSD > (David Leonard). The man page appears to have been written on > Jan 17, 1999 for OpenBSD. FreeBSD-current and -stable came much > later. Ah, that's what I saw. Thanks for the clarification. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
In article <[EMAIL PROTECTED]>,
W Gerald Hicks <[EMAIL PROTECTED]> wrote:
>
> Convince me that nothing like the following exists in the
> ports framework and /usr/src and I'd be ok with a change
> *after* 4.0 release (repeats himself)
>
> # Makefile.foo
>
> FOOVAR=
>
> .
> .
> .
>
> BARVAR=${FOOVAR}
>
> baz:
> for i in ${BARVAR} ; do \
>${BLAP} $$i ; \
> done
>
>
> To me, changing it right now on the eve of -release
> would be gratuitous. Later I would be fine with it.
I agree that this is not the time to change it. But in the long run,
if the ports framework is misusing /bin/sh then the framework needs to
be fixed. We shouldn't let bugs there influence what we do with the
shell.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
> is not a word at all, so it can't be expanded, so I think > bash is corrent to complain about a syntax error. Epsilon anyone? I really don't care (honestly) but a null word can be considered a word too! In yacc-like terms: wordlist: | wordlist WORD ; It doesn't really matter until one considers perverse abuses of a shell, such as those embedded in a Makefile somewhere. FreeBSD's shell (and ksh93) both perform "correctly" IMHO and wouldn't make the change. I'm also not likely to declare a Jihad against such a change either :-) It doesn't hurt anything the way it is and represents a better generalization (IMHO again). Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
> I agree that this is not the time to change it. But in the long run, > if the ports framework is misusing /bin/sh then the framework needs to > be fixed. We shouldn't let bugs there influence what we do with the > shell. Haven't been convinced yet they are bugs :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help: interrupt timeout
My laptop running 3.4-RELEASE decided it doesn't want to boot. It was uncleanly shut down via the power switch by someone who thought they were shutting down a different machine. Now when it boots, running fsck gives this result: > chip0: rev 0x01 on pci0.0.0 > chip1: rev 0x02 on pci0.7.0 > ide_pci0: rev 0x01 on pci0.7.1 > ... > wdc0 at 0x1f0-0x3f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (atapi): , removable, accel, dma, iordis > ... > # fsck / > *** /dev/rwd0s3a > *** Last Mounted on / > *** Root file system > *** Phase 1 - Check Blocks and Sizes > wd0: interrupt timeout (status 58 error 0) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: Last time I say: interrupt timeout. Probably a portable PC. (status >50 error 1) Well, yes in fact it is a portable PC :-) It just seems to hang at this point, even though there seems to be disk activity (like it's continuously retrying). This machine has run fine under this kernel since I installed 3.4-REL a month ago or so. This same problem happens with the 3.4-REL GENERIC kernel. Before this, it was running fine with a 3.0++ kernel and never had this problem after many power cycles. Is there any hope in getting this machine to work again?? Howabout disabling DMA? Is there some way to do that? Thanks for any pointers.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help: interrupt timeout
I've had the same problem. Most people have told me that I have to replace the hard drive. I never had the problem before 3.4. Maybe that's just a coincidence, though. -- Chris Byrnes (CB5820) Network Engineer, High Stability Internet Services http://www.highstability.com On Mon, 6 Mar 2000, Archie Cobbs wrote: > My laptop running 3.4-RELEASE decided it doesn't want to boot. > It was uncleanly shut down via the power switch by someone > who thought they were shutting down a different machine. > > Now when it boots, running fsck gives this result: > > > chip0: rev 0x01 on pci0.0.0 > > chip1: rev 0x02 on pci0.7.0 > > ide_pci0: rev 0x01 on pci0.7.1 > > ... > > wdc0 at 0x1f0-0x3f7 irq 14 on isa > > wdc0: unit 0 (wd0): > > wd0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T 512 B/S > > wdc1 at 0x170-0x177 irq 15 on isa > > wdc1: unit 0 (atapi): , removable, accel, dma, iordis > > ... > > # fsck / > > *** /dev/rwd0s3a > > *** Last Mounted on / > > *** Root file system > > *** Phase 1 - Check Blocks and Sizes > > wd0: interrupt timeout (status 58 error 0) > > wd0: wdtimeout DMA status 4 > > wd0: interrupt timeout (status 50 error 1) > > wd0: wdtimeout DMA status 4 > > wd0: interrupt timeout (status 50 error 1) > > wd0: wdtimeout DMA status 4 > > wd0: interrupt timeout (status 50 error 1) > > wd0: wdtimeout DMA status 4 > > wd0: interrupt timeout (status 50 error 1) > > wd0: wdtimeout DMA status 4 > > wd0: Last time I say: interrupt timeout. Probably a portable PC. (status >50 error 1) > > Well, yes in fact it is a portable PC :-) It just seems to hang > at this point, even though there seems to be disk activity (like > it's continuously retrying). > > This machine has run fine under this kernel since I installed > 3.4-REL a month ago or so. This same problem happens with the > 3.4-REL GENERIC kernel. > > Before this, it was running fine with a 3.0++ kernel and never > had this problem after many power cycles. > > Is there any hope in getting this machine to work again?? > Howabout disabling DMA? Is there some way to do that? > > Thanks for any pointers.. > -Archie > > ___ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help: interrupt timeout
I sometimes have this problem with my pc. Usually, a good kick will get it to boot. Sometimes on laptops and stuff the hard drive cable gets loose or something. Or, it's a bad hard drive. Try giving is a shove. --bhishan > I've had the same problem. Most people have told me that I have to > replace the hard drive. > > I never had the problem before 3.4. Maybe that's just a coincidence, > though. > > > -- > Chris Byrnes (CB5820) > Network Engineer, High Stability Internet Services > http://www.highstability.com > > On Mon, 6 Mar 2000, Archie Cobbs wrote: > > > My laptop running 3.4-RELEASE decided it doesn't want to boot. > > It was uncleanly shut down via the power switch by someone > > who thought they were shutting down a different machine. > > > > Now when it boots, running fsck gives this result: > > > > > chip0: rev 0x01 on pci0.0.0 > > > chip1: rev 0x02 on pci0.7.0 > > > ide_pci0: rev 0x01 on pci0.7.1 > > > ... > > > wdc0 at 0x1f0-0x3f7 irq 14 on isa > > > wdc0: unit 0 (wd0): > > > wd0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T 512 B/S > > > wdc1 at 0x170-0x177 irq 15 on isa > > > wdc1: unit 0 (atapi): , removable, accel, dma, >iordis > > > ... > > > # fsck / > > > *** /dev/rwd0s3a > > > *** Last Mounted on / > > > *** Root file system > > > *** Phase 1 - Check Blocks and Sizes > > > wd0: interrupt timeout (status 58 error 0) > > > wd0: wdtimeout DMA status 4 > > > wd0: interrupt timeout (status 50 error 1) > > > wd0: wdtimeout DMA status 4 > > > wd0: interrupt timeout (status 50 error 1) > > > wd0: wdtimeout DMA status 4 > > > wd0: interrupt timeout (status 50 error 1) > > > wd0: wdtimeout DMA status 4 > > > wd0: interrupt timeout (status 50 error 1) > > > wd0: wdtimeout DMA status 4 > > > wd0: Last time I say: interrupt timeout. Probably a portable PC. (status >50 error 1) > > > > Well, yes in fact it is a portable PC :-) It just seems to hang > > at this point, even though there seems to be disk activity (like > > it's continuously retrying). > > > > This machine has run fine under this kernel since I installed > > 3.4-REL a month ago or so. This same problem happens with the > > 3.4-REL GENERIC kernel. > > > > Before this, it was running fine with a 3.0++ kernel and never > > had this problem after many power cycles. > > > > Is there any hope in getting this machine to work again?? > > Howabout disabling DMA? Is there some way to do that? > > > > Thanks for any pointers.. > > -Archie > > > > ___ > > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > 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: empty lists in for (/bin/sh)
hi, there!
On Mon, 6 Mar 2000, Martin Cracauer wrote:
> I just checked POSIX 1003.2.
>
> for name [ in word ]
> do
> compound-list
> done
>
> "First, the list of words following 'in' shall be expanded to generate
> a list of items." [...] "If no items result from the expansion, the
> compound-list shall not be executed."
>
> is not a word at all, so it can't be expanded, so I think
> bash is corrent to complain about a syntax error.
>
> It is clear, though, that your (John) example "variable expansion to
> nothing" is not an error and both shells do it right.
A lot of stuff in /usr/ports/Mk/bsd.port.mk depends on current /bin/sh
behaviour ("do nothing" instead of "complain and bail out").
I am the original poster and faced this problem when tried to port FreeBSD
Ports subsystem to Solaris and Linux.
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for (/bin/sh)
In <[EMAIL PROTECTED]>, Max Khon wrote:
> hi, there!
>
> On Mon, 6 Mar 2000, Martin Cracauer wrote:
>
> > I just checked POSIX 1003.2.
> >
> > for name [ in word ]
> > do
> > compound-list
> > done
> >
> > "First, the list of words following 'in' shall be expanded to generate
> > a list of items." [...] "If no items result from the expansion, the
> > compound-list shall not be executed."
> >
> > is not a word at all, so it can't be expanded, so I think
> > bash is corrent to complain about a syntax error.
> >
> > It is clear, though, that your (John) example "variable expansion to
> > nothing" is not an error and both shells do it right.
>
> A lot of stuff in /usr/ports/Mk/bsd.port.mk depends on current /bin/sh
> behaviour ("do nothing" instead of "complain and bail out").
> I am the original poster and faced this problem when tried to port FreeBSD
> Ports subsystem to Solaris and Linux.
Hm,
for s in ${SUBDIR}; do
Well, the trick here is that ${SUBDIR} is expanded by make, not sh, so
sh can end up with nothing.
Max, I apologize, your point is valid and I commented without seeing
your original message.
OK, I think we should leave the non-word syntax as valid in FreeBSD,
since it makes the ports case more elegant and POSIX make it that
clear that sh must raise an error.
Max, I think the best way to port the ports subsystem is to take
FreeBSD's sh with you and point ${SH} to it, not the system's native
sh. Many native sh's have other things they do different from
FreeBSD's sh and bash (i.e. reaction on SIGINT, see
http://www.cons.org/cracauer/sigint.html), so I think this will
shorten your path considerably.
Martin
--
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
hi, there!
On Sun, 5 Mar 2000, Chris Costello wrote:
>ksh doesn't claim to be POSIX compliant?
>
> "ksh is intended to conform to the Shell Language Standard
> developed by the IEEE POSIX 1003.2 Shell and Utilities Language
> Committee."
>-- http://www.kornshell.com/info/
>
>And on a FreeBSD-compiled binary of the real AT&T ksh code:
>
> $ echo ${.sh.version}
> Version M 1993-12-28 i
> $ for i in ; do echo $i; done
> $
However, under Solaris 2.6:
clone$uname -a
SunOS clone 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-1-Engine
clone$/bin/ksh
clone$for i in ; do echo $i; done
/bin/ksh: syntax error: `;' unexpected
clone$
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Sat, 04 Mar 2000 15:36:43 +0200, Sheldon Hearn wrote: > I seem to remember POSIX being ambiguous on this one, but my books > are at the office. If you haven't gotten a more conclusive answer by > Monday, mail me and I'll look it up. I was wrong about POSIX being ambiguous in this regard; it's SUSV2 which is ambiguous. From POSIX.2 3.9.4.2: First, the list of words following _in_ shall be expanded to generate a list of items. Then, the variable shall be set to each item, in turn, and the executed each time. If no items result from the expansion, the shall not be executed. [...] Exit Status: The exit status of a _for_ command shall be the exit status of the last command that executes. If there are no items, the exit status shall be zero. > Neither bash nor ksh claim to be particularly POSIX compliant. our > /bin/sh does. This is the part of my original post that Doug barton objected to. Perhaps bash has POSIX compliance as one of its goals, which invalidates my original statement. On this score, however, both bash and ksh are not compliant. Once again, our shell comes out tops. :-) Ciao, Sheldong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
Sheldon Hearn wrote: > > On Sat, 04 Mar 2000 15:36:43 +0200, Sheldon Hearn wrote: > > > I seem to remember POSIX being ambiguous on this one, but my books > > are at the office. If you haven't gotten a more conclusive answer by > > Monday, mail me and I'll look it up. > > I was wrong about POSIX being ambiguous in this regard; it's SUSV2 which > is ambiguous. From POSIX.2 3.9.4.2: > > First, the list of words following _in_ shall be expanded to > generate a list of items. Then, the variable shall be > set to each item, in turn, and the executed each > time. If no items result from the expansion, the > shall not be executed. [...] > > Exit Status: The exit status of a _for_ command shall be the > exit status of the last command that executes. If there are no > items, the exit status shall be zero. > > > Neither bash nor ksh claim to be particularly POSIX compliant. our > > /bin/sh does. > > This is the part of my original post that Doug barton objected to. > Perhaps bash has POSIX compliance as one of its goals, which invalidates > my original statement. On this score, however, both bash and ksh are > not compliant. I think that Martin's post contained the informative bit: I just checked POSIX 1003.2. for name [ in word ] do compound-list done the "in word" is optional. Therefore: for name in ; do echo $name; done is an error, whereas for name ; do echo $name; done is not, and Bash does not report it as so, in or out of POSIX mode. Also, your snippet clearly expects that there will be a word after "in." It could easily be argued from that context that the presence of "in" without a "word" to go with it is an error, even without the bit from Martin's post. All that said, if the ports make system depends on the current behavior, it has to be fixed before we can contemplate any changes. Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Mon, 06 Mar 2000 00:59:39 PST, Doug Barton wrote: > for name [ in word ] > do > compound-list > done > > the "in word" is optional. Therefore: Hmmm, you're right. I must admit, though, that if the text is confusing enough to confuse me, it's not entirely clear (even if I'm not the hardest person in the world to confuse)! :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
In message <[EMAIL PROTECTED]> Sheldon Hearn writes: : On Mon, 06 Mar 2000 00:59:39 PST, Doug Barton wrote: : : > for name [ in word ] : > do : > compound-list : > done : > : > the "in word" is optional. Therefore: : : Hmmm, you're right. : : I must admit, though, that if the text is confusing enough to confuse : me, it's not entirely clear (even if I'm not the hardest person in the : world to confuse)! Are you sure that "word" here means one or more tokens, or zero or more tokens. If it means zero or more tokens, then 'for i in ; do ' is perfectly legal. You're not quoting what word means. The reason that I ask this is that I can't see why for i in ; do would be any different than for i in $foo; do when foo is empty. They are the same thing from at last my world view of the shell. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Sheldon Hearn writes: > : On Mon, 06 Mar 2000 00:59:39 PST, Doug Barton wrote: > : > : > for name [ in word ] > : > do > : > compound-list > : > done > : > > : > the "in word" is optional. Therefore: > : > : Hmmm, you're right. > : > : I must admit, though, that if the text is confusing enough to confuse > : me, it's not entirely clear (even if I'm not the hardest person in the > : world to confuse)! > > Are you sure that "word" here means one or more tokens, or zero or > more tokens. If it means zero or more tokens, then 'for i in ; do ' > is perfectly legal. You're not quoting what word means. > > The reason that I ask this is that I can't see why > for i in ; do > would be any different than > for i in $foo; do > when foo is empty. They are the same thing from at last my world view > of the shell. The context of the text (previously quoted) clearly expects that "word" be expanded. An expansion which evaluates to an empty set is different from a lack of "word" to be expanded at all. That's why "in word" is optional, but "word" isn't. IIRC, $name can be set outside of the expression, which would allow it to be acted on within the list. At the same time, I'd also like to see if POSIX has a clear definition of "word." Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Mon, 06 Mar 2000 01:44:35 PST, Doug Barton wrote: > At the same time, I'd also like to see if POSIX has a clear definition > of "word." Aha, that's what we should have looked at right in the beginning. My take on POSIX.2 3.10.2 (Shell Grammar Rules) is that _word_ may not be the empty string. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Copy-on-write filesystem
On Fri, 3 Mar 2000, Mike Smith wrote: > > Actually, since this is copy-on-write, you do not need the block, until > > you write. If you need to make a copy, it will be on a write system call > > (possibly an inode update), just fail the write ENOSPC or whatever. Or am > > I missing something simple here. > > Failing a write into the middle of an existing file with ENOSPC is going > to break any application that's not expecting a potentially sparse file... It's an application problem, isn't it? Any write() can fail, with EIO, for example. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Pthread blocking I/O
Hi, I use two threads to do I/O for a process. The I/O takes place either on a socket or an I/O device (com port) file descriptor. Apparently it is not possible to shutdown those threads from a third thread, neither using close nor shutdown(2) for the socket I/O if the threads are blocked during read. What methods can one use to unblock such a blocked-on-read thread? Thanks, TITUS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
Hi, I have not so much experience using POSIX threads, but we had in university a project and for I/O to use threads is not so good method. You slow down the process. Some comments? Isn't so? stefan Titus von Boxberg wrote: > > Hi, > > I use two threads to do I/O for a process. > The I/O takes place either on a socket or > an I/O device (com port) file descriptor. > > Apparently it is not possible to shutdown those > threads from a third thread, neither using close nor shutdown(2) for > the socket I/O if the threads are blocked during read. > > What methods can one use to unblock such a blocked-on-read > thread? > > Thanks, > > TITUS > > 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: MAXUSERS question, what is max MAXUSERS setting?
well i bumped it to 512 and nmbclusters to 32768 on several machines that got 5000+ (!) http requests a second... the problem is the number of maximum open files in the system (32k in this case) and open sockets. /k -- The path of excess leads to the tower of wisdom. -W. Blake Karsten W. Rohrbach - Senior Research Engineer - Nacamar Data Communications one world. one net. nacamar - http://www.nacamar.net This was written on the road... Answers to your reply could be delayed. - Original Message - From: "Egervary Gergely" <[EMAIL PROTECTED]> To: "Karsten W. Rohrbach" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, March 02, 2000 9:51 AM Subject: Re: MAXUSERS question, what is max MAXUSERS setting? > > i just wondered what the maximum MAXUSERS setting for a 3.4 kernel would > > be on a smp system with 512mb ram... the impact on the system structures > > seems to be very... errrhh... rather complex. > > > > any ideas? it gives me a warning if i got past 512, but what will happen > > then? > > see conf/param.c to see what it means. > > I don't thing you need to set it >128, if you have large network traffic, > you should increase NMBCLUSTERS, and other VM limits. > > -- mauzi > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
> I use two threads to do I/O for a process. > The I/O takes place either on a socket or > an I/O device (com port) file descriptor. > > Apparently it is not possible to shutdown those > threads from a third thread, neither using close nor shutdown(2) for > the socket I/O if the threads are blocked during read. > > What methods can one use to unblock such a blocked-on-read > thread? The current implementation of FreeBSD pthreads only grants access to file descriptors to one thread at a time. I think if one thread tries to close a file descriptor from which another thread is reading, that the thread trying to close will block until the read completes. You can use pthread_kill() or pthread_cancel(). pthread_kill() should unblock the thread in a read state and return -1 with errno = EINTR. There were some bugs with signal handling that were fixed in -stable, so make sure you are running a relatively recent version. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
* stefan parvu ([EMAIL PROTECTED]) [000306 09:19]: > I have not so much experience using POSIX threads, but we had in > university a project and for I/O to use threads is not so good method. > You slow down the process. > > Some comments? Isn't so? In my experience, threads are the perfect way to speed up an I/O bound application. While one thread is blocked in iowait, others can be performing operations that do not contend for the same resource (calculation, I/O on some other resource like a socket, etc.) This is of course implementation dependant; if you are using a user-land thread package like MIT pthreads, the kernel sees the entire process as one schedulable entity, so if one thread blocks on IO, all threads block. If you are using a kernel-thread or hybrid implementation, the system scheduler allows the other threads to run as described above. FreeBSD's threading implementation in libc_r is (AFAIK) a hybrid model, and from personal experience I have found threaded applications under FreeBSD to be much easier to code for performance than their single-threaded counterparts. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
On Mon, 6 Mar 2000, James FitzGibbon wrote: > > Some comments? Isn't so? > > In my experience, threads are the perfect way to speed up an I/O bound > application. While one thread is blocked in iowait, others can be > performing operations that do not contend for the same resource > (calculation, I/O on some other resource like a socket, etc.) Processes can do it better, and if i/o can be nonblocking, plain poll()/select() loop can do even better (pathological cases of Java and applications ported from Windows being the exception). > > This is of course implementation dependant; if you are using a user-land > thread package like MIT pthreads, the kernel sees the entire process as one > schedulable entity, so if one thread blocks on IO, all threads block. Not really. What looks like blocking i/o for you can be nonblocking for kernel if your threads support library translates it. > If > you are using a kernel-thread or hybrid implementation, the system scheduler > allows the other threads to run as described above. > > FreeBSD's threading implementation in libc_r is (AFAIK) a hybrid model, and > from personal experience I have found threaded applications under FreeBSD to > be much easier to code for performance than their single-threaded > counterparts. My experience is the opposite -- if data structures are complex enough to become a pain in the ass to lock, processes allow more simple design than threads, and nonblocking i/o usually limits complex code to some small piece of program that can be written/optimized/debugged once, then left alone. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
Daniel Eischen wrote: > > > Apparently it is not possible to shutdown those > > threads from a third thread, neither using close nor shutdown(2) for > > the socket I/O if the threads are blocked during read. > > > > What methods can one use to unblock such a blocked-on-read > > thread? > > The current implementation of FreeBSD pthreads only grants access > to file descriptors to one thread at a time. I think if one thread and per direction (?) > tries to close a file descriptor from which another thread is > reading, that the thread trying to close will block until the > read completes. Thanks for your answer! What's the reason for locking the file descriptors for *all* system calls? especially those I mentioned? Where is pthread_cancel() ? TITUS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Pthread blocking I/O
[...] > What's the reason for locking the file descriptors > for *all* system calls? especially those I mentioned? > > Where is pthread_cancel() ? are you using -stable (3.x)? there is no ``pthread_cancel'' in -stable. use -current. or - use other threads library - use non-blocking read - use select/poll with timeout man pthread and see /usr/src/lib/libc_r/uthread for details. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Monday, March 06, 2000, Max Khon wrote:
> However, under Solaris 2.6:
> clone$uname -a
> SunOS clone 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-1-Engine
> clone$/bin/ksh
> clone$for i in ; do echo $i; done
> /bin/ksh: syntax error: `;' unexpected
> clone$
It is likely you are running the ksh88 version, which has
quite a few ``pre-POSIX'' features. Try this command to see
whether you have ksh88 or ksh93:
echo ${.sh.version}
If you have ksh93, you'll see something like
Version M 1993-12-28 i
Perhaps with a different letter at the end (`i' is the source
release). I believe you'll get an error or nothing if it's
ksh88.
--
|Chris Costello <[EMAIL PROTECTED]>
|Know Thy User.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
Max Khon <[EMAIL PROTECTED]> wrote: > However, under Solaris 2.6: > clone$uname -a > SunOS clone 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-1-Engine > clone$/bin/ksh > clone$for i in ; do echo $i; done > /bin/ksh: syntax error: `;' unexpected That's an old ksh88, which probably doesn't conform to POSIX anyway. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Keeping using locally modified source
On Thu, 02 Mar 2000 19:59:39 EST, James Howard wrote: > The problem is how do we keep up with -STABLE afterwards? Using > CVSup, out changes will get clobbered every time. Is there a facility > where you can keep up with the source but let local modifications > through? CVS does this beautifully. The only problem is that you need access to a repo. If you were closer, I'd offer you anoncvs. Try to find an anoncvs server near you. The most viable alternative I've used is a shell script that patches the checked out sources with copies of patches in a specified directory. This worked well for me until my local guru pointed out that what you want to do here is _exactly_ what CVS does for you. CVSup was not designed for synchronizing checked out sources (although it has certainly become very popular for just that). Here, you're running into a limitation of CVSup. Of course, since I haven't used CVSup in a long time, it's quite possible that jdp has added CVS-like merging and conflict resolution to CVSup. ;-) Hopefully, you either have good bandwidth or lots of disk. If you have good bandwidth, use CVS. If you have lots of disk, use CVSup to keep a local repo and use CVS to synchronize your checked out sources against that repo. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KLD's
I am busy to convert two lkm's to kld's and having some problem with it. The scenario is two lkm's ( now kld's ) which are loaded dependantly ( A and B ) I used to load them as : /sbin/modload -o /tmp/kern.sym ./A.o /sbin/modload -A /tmp/kern.sym ./B.o to keep the symbols available. The general layout of the modules used to look like the lkm examples they gave in /usr/share/examples/lkm/misc ( SPECIFICALLY misc one ) I couldn't get an example of a KLD looking like this one, there is only .../kld/cdev and /kld/syscall. So i used syscall examples. Then i compiled the module B.ko with A.ko as a dependancy. ( I think i did , specked KMODDEPS= cspop_mod.ko which is module A in the Makefile. I am loading with kldload ./A and kldload ./B ( it's the only way i know of ). But now it still looks as if the two modules dont know about each other. Is there an example of something like this lying around ??? How do i (link) the symbols to the second KLD loaded ??? -- Johan Kruger ( B.Ing Electronic Engineering ) Developement Engineer Nanoteq PTA ( 012 6727000 ) e-mail : [EMAIL PROTECTED] e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KLD's
I am busy to convert two lkm's to kld's and having some problem with it. The scenario is two lkm's ( now kld's ) which are loaded dependantly ( A and B ) I used to load them as : /sbin/modload -o /tmp/kern.sym ./A.o /sbin/modload -A /tmp/kern.sym ./B.o to keep the symbols available. The general layout of the modules used to look like the lkm examples they gave in /usr/share/examples/lkm/misc ( SPECIFICALLY misc one ) I couldn't get an example of a KLD looking like this one, there is only .../kld/cdev and /kld/syscall. So i used syscall examples. Then i compiled the module B.ko with A.ko as a dependancy. ( I think i did , specked KMODDEPS= cspop_mod.ko which is module A in the Makefile. I am loading with kldload ./A and kldload ./B ( it's the only way i know of ). But now it still looks as if the two modules dont know about each other. Is there an example of something like this lying around ??? How do i (link) the symbols to the second KLD loaded ??? -- Johan Kruger ( B.Ing Electronic Engineering ) Developement Engineer Nanoteq PTA ( 012 6727000 ) e-mail : [EMAIL PROTECTED] e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
Titus von Boxberg wrote: > Daniel Eischen wrote: > > > > > Apparently it is not possible to shutdown those > > > threads from a third thread, neither using close nor shutdown(2) for > > > the socket I/O if the threads are blocked during read. > > > > > > What methods can one use to unblock such a blocked-on-read > > > thread? > > > > The current implementation of FreeBSD pthreads only grants access > > to file descriptors to one thread at a time. I think if one thread > > and per direction (?) Yes, per direction. I think a close() will try to lock the file descriptor for both read and write though. > > tries to close a file descriptor from which another thread is > > reading, that the thread trying to close will block until the > > read completes. > Thanks for your answer! > > What's the reason for locking the file descriptors > for *all* system calls? especially those I mentioned? I dunno. That's the way it was implemented when I started working on the threads library. I suppose to protect poorly written programs from themselves? I haven't found anything in the POSIX spec that directly addresses this issue, but I haven't spent the time to thoroughly read the spec either. You certainly want to make accesses/modifications to FILE types atomic/protected, but I think it's the applications responsibilty to synchronize access to file descriptors for I/O. As in your example, I think you should allow one thread to close a file descriptor while another thread is reading from it. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
> On Mon, 21 Feb 2000 22:10:15 +0600, Max Khon wrote: > > > bash and ksh complain about unexpected ';'. > > /bin/sh (FreeBSD) thinks it's ok and does nothing. > > Which behaviour is more POSIXly correct? > > Neither bash nor ksh claim to be particularly POSIX compliant. Bash claims POSIX.2 compliance. If you have specific reports of non-compliance, send them to [EMAIL PROTECTED] -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet) Chet Ramey, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
> Even though it's my preferred shell, I certainly wouldn't say
> that Bash is any sort of standard, certainly not in the POSIX
> sense.
Bash implements the POSIX.2 standard, with certain well-defined
exceptions (`posix mode').
> Imagine processing a possibly empty list constructed from a
> 'make' expansion... Without this behavior one would have to
> code a guard of some sort around the 'for' construct.
The idiomatic solution for this sort of thing is changing
your makefile recipes from
for f in ${SUBDIRS} do ...
to
sh_subdirs=${SUBDIRS}; for f in $$sh_subdirs ; do ...
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)
Chet Ramey, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
> Are you sure that "word" here means one or more tokens, or zero or > more tokens. If it means zero or more tokens, then 'for i in ; do ' > is perfectly legal. You're not quoting what word means. The standard says that `word' may not be the empty string. POSIX.2, 3.10. > The reason that I ask this is that I can't see why > for i in ; do > would be any different than > for i in $foo; do > when foo is empty. They are the same thing from at last my world view > of the shell. Because parsing and expansion are different things, and expansion is performed after a command has been completely parsed. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet) Chet Ramey, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
It is back
Remember a few months back when it was mentioned that the Netgear FS-105 was on sale at CompUSA. Wel Frye's Electronics has them on sale till tomorrow for $93.99. Just thought I would let people know there is a second chance. TIA -- --- Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * [EMAIL PROTECTED]and all was /dev/null and *void() --- A PBS mind in a MTV world To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: It is back
On Mon, 06 Mar 2000, Ron 'The InSaNe One' Rosson was heard blurting out: > Remember a few months back when it was mentioned that the Netgear FS-105 > was on sale at CompUSA. Wel Frye's Electronics has them on sale till > tomorrow for $93.99. Just thought I would let people know there is a > second chance. > Oooppp!!! I forgot to tell what it is for the people seeing this for the first time.. It is a 5port 10/100 switch. -- --- Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * [EMAIL PROTECTED]and all was /dev/null and *void() --- Is it time for your medication or mine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to fdisk/disklabel whole disk for FreeBSD from command line?
In message <[EMAIL PROTECTED]>, Warner Losh writes: > In message <[EMAIL PROTECTED]> Doug White >writes: > : > fdisk -e /dev/rda1 > : > disklabel -r -w da1 auto > : > : Yeah, this is wrong. You need to specify a slice. > > But you can't specify a slice here. It won't work. If you give it > the whole path, disklabel won't even try. If you day da1s1, it will > complain that it can't fit a disklabel for the entire disk into the > slice smaller than the disk with some cryptic error message or another > :-). Probably an error like 'No space left on device' (the error message I talked about in my original posting about this problem). :) > : I generally don't depend on the 'auto' magic -- it breaks for IDE > : disks, and I'm not sure it works for slices either. > > It breaks for all disk lables that aren't the entire disk. Thanks, this is VERY helpful information to me -- I was expecting 'auto' mode to work on an fdisk slice, and knowing that it doesn't work there tells me to pursue less optimal options. > : I'm looking at the script and notice that it doesn't select slice > : 1... somehow disklabel DTRT. It works here :-) > > Well, you could look at my diskprep script that I just posted a > reference to. > http://people.freebsd.org/~imp/diskprep > (also needs patches to fdisk: > http://people.freebsd.org/~imp/fdisk-patch) I'd like to commit it to > FreeBSD after 4.0 goes out the door. We have many partital solutions > to this problem. It is time to make a simple, standard tool to do > this. No, sysinstall doesn't count here because it isn't simple and > cannot be driven from a script. The fla tool is limited to fla DOC2K > disks. The prepdisk in picobsd has too many things hard coded and > will work only for ide disks. > > It is designed to create a sane slice (ala fdisk -I (since -e -> -I > soon)) and put a reasonable disklabel on it. By default it does only > one partition, but can be configured to do more. I wrote it to deal > with creating dozens of compact flash labeling when I'm given a hodge > podge of CF sizes and manufactures to create images for (sometimes 48M > parts are available, other times 45M parts, and each of those sizes > varies +- 300 blocks between vendors). > > Warner Warner, thanks for the diskprep reference. I was hoping there was some automagic disklabel command flag I was missing to automatically create a valid FreeBSD partition table that covers a whole FreeBSD slice, but after the many messages in this thread, I've come to the conclusion that 'fdisk -e' (or -I as it will become) can automatically create the fdisk slice, but the FreeBSD disklabel parameters must be calculated externally from disklabel, requiring a script, such as prepdisk. In short, the disklabel command simply doesn't have the capability to automatically create a label that covers an entire FreeBSD fdisk slice. Note that disklabel auto mode works fine if you want to use "Dangerously dedicated mode", which I do not. I have written my own Perl script that reads dmesg to get the disk geometry and then generates a proper FreeBSD partition (disklabel) label, and have verified that I can get the result I want this way. A problem with both prepdisk and my script is that it depends on the format of the kernel autoconfiguration entry for the sizes of disks to stay relatively static. The message format changed recently, and future such changes will cause our scripts to break. I believe the right solution to all this is to use a C program doing ioctl's on the raw device to get disk geometry info, and then using libdisk to write a proper label. Just as a side note, I discovered that 'fdisk -e' produces a different ending cylinder number on the fdisk slice than sysinstall, even though the number of sectors in the fdisk slice between the two methods are identical. This doesn't seem to effect operation at all, but I'd guess that the sysinstall number of 1023 is probably more accurate than the less-than 1023 numbers I get with 'fdisk -e'. This is probably a bug in 'fdisk -e'. ...Marc... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Pthread blocking I/O
On 06-Mar-00 Yevmenkin, Maksim N, CSCIO wrote: > [...] > >> What's the reason for locking the file descriptors >> for *all* system calls? especially those I mentioned? >> >> Where is pthread_cancel() ? > > are you using -stable (3.x)? there is no ``pthread_cancel'' in -stable. > use -current. Bt!!! Wrong! > uname -a FreeBSD server.baldwin.cx 3.4-STABLE FreeBSD 3.4-STABLE #6: Sun Feb 20 20:24:19 EST 2000 [EMAIL PROTECTED]:/usr/source/src/sys/compile/SERVER i386 > man -k pthread_cancel pthread_cancel(3) - cancel execution of a thread > nm /usr/lib/libc_r.so | grep pthread_cancel 00078524 T pthread_cancel You do need a fairly recent -stable, but it's in there. :) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On 06-Mar-00 Doug Barton wrote: > I just checked POSIX 1003.2. > > for name [ in word ] > do > compound-list > done > > the "in word" is optional. Therefore: > > for name in ; do echo $name; done > > is an error, whereas > > for name ; do echo $name; done These are two different functions. The second one loops through the command line parameters. > is not, and Bash does not report it as so, in or out of POSIX mode. > Also, your snippet clearly expects that there will be a word after "in." > It could easily be argued from that context that the presence of "in" > without a "word" to go with it is an error, even without the bit from > Martin's post. > > All that said, if the ports make system depends on the current > behavior, it has to be fixed before we can contemplate any changes. Patches accepted. > Doug -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to fdisk/disklabel whole disk for FreeBSD from command line?
In message <[EMAIL PROTECTED]> Marc Frajola writes: : I have written my own Perl script that reads dmesg to get the disk : geometry and then generates a proper FreeBSD partition (disklabel) : label, and have verified that I can get the result I want this way. Bad idea. Too many different formats. Also, it doesn't work for removable media like CF cards. The format for scsi is different than ata, and ata changed recently.You also have problems with slow SCSI devices that take a while to print their probe messages. If it is after /var/run/dmesg.boot is created you won't find them there. And if you are using the dmesg buffer, it can wrap with log messages before you try to access the disk. : A problem with both prepdisk and my script is that it depends on : the format of the kernel autoconfiguration entry for the sizes of : disks to stay relatively static. The message format changed recently, : and future such changes will cause our scripts to break. My diskprep doesn't break. I don't parse the boot messages. I tell fdisk to give me the information, and then use it. That's why I said that it depended fdisk patches. fdisk -s after the change will do the right thing and give good summary information. : I believe the right solution to all this is to use a C program : doing ioctl's on the raw device to get disk geometry info, and then : using libdisk to write a proper label. Uggg. I've had less than good luck with libdisk. It is completely broken for me right now. This is even when I do a build world and install a kernel at the same time.. Something to do with the raw/block changes a while ago? I can't seem to get this to work at all, and it is quite frustrating since it would be ideal. I may try again later, but for now libdisk has left a bad taste in my mouth... : Just as a side note, I discovered that 'fdisk -e' produces a : different ending cylinder number on the fdisk slice than sysinstall, : even though the number of sectors in the fdisk slice between the two : methods are identical. This doesn't seem to effect operation at all, : but I'd guess that the sysinstall number of 1023 is probably more : accurate than the less-than 1023 numbers I get with 'fdisk -e'. This is : probably a bug in 'fdisk -e'. Not sure about this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Mon, 06 Mar 2000 12:04:53 EST, Chet Ramey wrote: > Bash claims POSIX.2 compliance. If you have specific reports of > non-compliance, send them to [EMAIL PROTECTED] I spoke out of turn. Please permit me to extract my foot from my mouth and try to reattach it to some part of the body that'll have more use for it. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Pthread blocking I/O
[...] > > are you using -stable (3.x)? there is no ``pthread_cancel'' > in -stable. > > use -current. > > Bt!!! Wrong! > > > uname -a > FreeBSD server.baldwin.cx 3.4-STABLE FreeBSD 3.4-STABLE #6: > Sun Feb 20 20:24:19 EST 2000 > [EMAIL PROTECTED]:/usr/source/src/sys/compile/SERVER i386 > > man -k pthread_cancel > pthread_cancel(3) - cancel execution of a thread > > nm /usr/lib/libc_r.so | grep pthread_cancel > 00078524 T pthread_cancel xxx:/usr/home/xxx> uname -a FreeBSD xxx.xxx.ru 3.4-STABLE FreeBSD 3.4-STABLE #4: Mon Jan 3 16:01:58 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/xxx i386 xxx:/usr/home/xxx> man -k pthread_cancel pthread_cancel: nothing appropriate xxx:/usr/home/xxx> xxx:/usr/home/xxx> nm /usr/lib/libc_r.so | grep pthread_cancel xxx:/usr/home/xxx> > You do need a fairly recent -stable, but it's in there. :) indeed :-) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Pthread blocking I/O
On Mon, 6 Mar 2000, Yevmenkin, Maksim N, CSCIO wrote: > [...] > > > > are you using -stable (3.x)? there is no ``pthread_cancel'' > > in -stable. > > > use -current. > > > > Bt!!! Wrong! > > > > > uname -a > > FreeBSD server.baldwin.cx 3.4-STABLE FreeBSD 3.4-STABLE #6: > > Sun Feb 20 20:24:19 EST 2000 > > [EMAIL PROTECTED]:/usr/source/src/sys/compile/SERVER i386 > > > man -k pthread_cancel > > pthread_cancel(3) - cancel execution of a thread > > > nm /usr/lib/libc_r.so | grep pthread_cancel > > 00078524 T pthread_cancel > > xxx:/usr/home/xxx> uname -a > FreeBSD xxx.xxx.ru 3.4-STABLE FreeBSD 3.4-STABLE #4: Mon Jan 3 16:01:58 EST > 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/xxx i386 > > xxx:/usr/home/xxx> man -k pthread_cancel > pthread_cancel: nothing appropriate > xxx:/usr/home/xxx> > > xxx:/usr/home/xxx> nm /usr/lib/libc_r.so | grep pthread_cancel > xxx:/usr/home/xxx> > > > You do need a fairly recent -stable, but it's in there. :) > > indeed :-) You're a day too old. The cancellation functions were brought into -stable on January 4th. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
In message <[EMAIL PROTECTED]> Chet Ramey writes:
: The idiomatic solution for this sort of thing is changing
: your makefile recipes from
:
: for f in ${SUBDIRS} do ...
:
: to
:
: sh_subdirs=${SUBDIRS}; for f in $$sh_subdirs ; do ...
That's much better than what I've tended to do:
for f in x ${FOO}; do
if [ $f != x ]; then
fi
done
there's lots of other workarounds, from seeing if SUBDIRS is defined,
to using make's .foreach.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>: to
>:
>: sh_subdirs=${SUBDIRS}; for f in $$sh_subdirs ; do ...
>
>there's lots of other workarounds, from seeing if SUBDIRS is defined,
>to using make's .foreach.
Another option is:
for f in $$empty_list ${SUBDIRS}; do ...
where 'empty_list' is any undefined sh variable.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Mon, Mar 06, 2000 at 01:45:44PM -0500, John Baldwin wrote:
>
> On 06-Mar-00 Doug Barton wrote:
> > All that said, if the ports make system depends on the current
> > behavior, it has to be fixed before we can contemplate any changes.
>
> Patches accepted.
The construction
set -- ${MAKE_MACRO} ; for i ; do echo $i; done
seems to do what we want. Well, it works with bash and
freebsd's sh.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: It is back
Ron 'The InSaNe One' Rosson wrote: > > Remember a few months back when it was mentioned that the Netgear FS-105 > was on sale at CompUSA. Wel Frye's Electronics has them on sale till > tomorrow for $93.99. Just thought I would let people know there is a > second chance. I'm very happy with mine. c|net shopper shows the list price as $95.00 now, and prices as low as $81.05. buy.com has them for $82.95. http://www.shopper.com/ is your friend here. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
> In message <[EMAIL PROTECTED]>, Warner Losh writes:
>
> >: to
> >:
> >:sh_subdirs=${SUBDIRS}; for f in $$sh_subdirs ; do ...
> >
>
> >there's lots of other workarounds, from seeing if SUBDIRS is defined,
> >to using make's .foreach.
>
> Another option is:
>
> for f in $$empty_list ${SUBDIRS}; do ...
>
> where 'empty_list' is any undefined sh variable.
Not bad, but will break if the shell is run with the `-u' option on
for some reason.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)
Chet Ramey, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
John Baldwin wrote: > > On 06-Mar-00 Yevmenkin, Maksim N, CSCIO wrote: > > [...] > > > >> What's the reason for locking the file descriptors > >> for *all* system calls? especially those I mentioned? > >> > >> Where is pthread_cancel() ? > > > > are you using -stable (3.x)? there is no ``pthread_cancel'' in -stable. > > use -current. > > Bt!!! Wrong! > > [system info elided...] > > You do need a fairly recent -stable, but it's in there. :) >From the manpage, I'd guess the magic date to be on or about Jan 17, 2000. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Where is pci_intr_establish() & _thread_sys_read()?
Can anyone tell me where is the code for pci_intr_establish() and _thread_sys_read()? I could not find them under /usr/src. Thanks, -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
On Mon, 6 Mar 2000, Wes Peters wrote: > John Baldwin wrote: > > > > On 06-Mar-00 Yevmenkin, Maksim N, CSCIO wrote: > > > [...] > > > > > >> What's the reason for locking the file descriptors > > >> for *all* system calls? especially those I mentioned? > > >> > > >> Where is pthread_cancel() ? > > > > > > are you using -stable (3.x)? there is no ``pthread_cancel'' in -stable. > > > use -current. > > > > Bt!!! Wrong! > > > > [system info elided...] > > > > You do need a fairly recent -stable, but it's in there. :) > > >From the manpage, I'd guess the magic date to be on or about Jan 17, > 2000. I used the CVS logs for src/lib/libc_r/uthread/uthread_cancel.c: revision 1.2.2.1 date: 2000/01/04 10:42:19; author: tg; state: Exp; lines: +1 -1 MFC: Cancellation functions. Reviewed by:deischen = Some of the man pages and cancellation support came from OpenBSD (David Leonard). The man page appears to have been written on Jan 17, 1999 for OpenBSD. FreeBSD-current and -stable came much later. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rpc.lockd and xdr.
Version 2 of the lock manager is ready to be released. Amitha
says that it passes all of the tests in the suite posted by Drew (thanks
Drew). A noteable exception to this is on SGI where some lock requests
are never even received from the remote host. Also DOS sharing is not
yet complete.
On a side note, it would appear that at least some of the problems of the
previous version were in FreeBSD's XDR library. The xdr_*_int64 routines
do not correctly do network byte order conversions. Included below is
Amitha's 'hack fix'.
My hack fix (this is to /usr/src/lib/libc/xdr/xdr.c) is below. A similar
fix needs to be applied to xdr_int64_t. Note that xdr_opaque takes care of
swapping the bits in the byte.
#define SWAP(a,b,t) t=a;a=b;b=t
bool_t
my_xdr_u_int64_t(xdrs, uint64_p)
register XDR *xdrs;
u_int64_t *uint64_p;
{
u_int64_t x;
unsigned char* b= &x;
unsigned char t;
switch (xdrs->x_op) {
case XDR_ENCODE:
SWAP(b[0], b[7], t);
SWAP(b[1], b[6], t);
SWAP(b[2], b[5], t);
SWAP(b[3], b[4], t);
return (xdr_opaque(xdrs, (caddr_t)uint64_p, sizeof(u_int64_t)))
;
case XDR_DECODE:
if (!xdr_opaque(xdrs, (caddr_t)&x, sizeof x)) {
return (FALSE);
}
SWAP(b[0], b[7], t);
SWAP(b[1], b[6], t);
SWAP(b[2], b[5], t);
SWAP(b[3], b[4], t);
*uint64_p = x;
return (TRUE);
case XDR_FREE:
return (TRUE);
}
return (FALSE);
}
=
--
David Cross | email: [EMAIL PROTECTED]
Acting Lab Director | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself. | WinNT:Linux::Linux:FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
