Linux-Development-Sys Digest #63, Volume #8 Thu, 3 Aug 00 20:13:10 EDT
Contents:
Re: interruptible_sleep_on isn't working on multi-threaded app. ([EMAIL PROTECTED])
glibc bug? (tye4)
Re: glibc bug? (Kaz Kylheku)
glibc bug strtol (tye4)
eexpress patch
Re: glibc bug strtol (Kaz Kylheku)
Re: linux device drivers info (Kai Xu)
Re: read() and directories (Daniel P. Katz)
Re: read() and directories (Pete Zaitcev)
Re: read() and directories (Dave Platt)
Re: glibc bug? (Pete Zaitcev)
Re: glibc bug strtol (tye4)
Re: ntfs support in kernel 2.2.14? ("D. Stimits")
Can't get a framebuffer console ("Nikhil G. Daddikar")
Re: read() and directories (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: interruptible_sleep_on isn't working on multi-threaded app.
Date: Thu, 03 Aug 2000 19:20:34 GMT
>
> > >> 2. I tried to replace the interruptible_sleep_on with the sleep
for
> > >> the feature to work.
> > >> But when i call the sleep_on my whole task gets blocked. I want
to
> > >> block only the thread calling the blocking ioctl.
> > >
> > >What kind of thread you're using? POSIX threads know user level
> > >and system level scheduling.
> >
> > Two level scheduling isn't part of POSIX, but is rather a feature of
> > some implementations. Solaris works the way you describe, but Linux
> > does not, it has only system level scheduling.
>
> Iam using posix threads right now.
>
> > If you're using user level scheduling
> > >(which is the default), each system call blocks the whole
> application
> > >with all threads in it, because the system doesn't know anything
> > >about the threads. So you should switch to system scheduling. Look
> > >at pthread_attr_setschedpolicy().
>
> > There is no POSIX interface for doing this. The
> pthread_attr_setschedpolicy
> > function can be used to select SCHED_OTHER, SCHED_RR or SCHED_FIFO
> which have
> > little to do with user versus kernel scheduling.
>
1. I understand that linux implements posix threads in user level.
Isn't "pthread_attr_setschedpolicy" used for user level thread
scheduling?
2. Does linux have system level thread (I have to support redhat 6.1
(kernel ver 2.2.12))?
How can I use to solve this problem.(Even if it means using non-POSIX
interface)
Another question
3. Since the pthread library internally use clone I am effectively
getting different PID (even in driver). But I cannot sleep any one
thread. Why?
Regards
jeseem
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Subject: glibc bug?
Date: Thu, 03 Aug 2000 13:14:31 -0700
A NULL passed to strcmp() and similar functions causes segmentation
fault:
// crash
strcmp( NULL, "something" );
strcmp( "something", NULL );
Is this a bug, or are my man pages outdated?
tye4
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: glibc bug?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 03 Aug 2000 20:35:03 GMT
On Thu, 03 Aug 2000 13:14:31 -0700, tye4 <[EMAIL PROTECTED]> wrote:
>A NULL passed to strcmp() and similar functions causes segmentation
>fault:
>
>// crash
>strcmp( NULL, "something" );
>strcmp( "something", NULL );
>
>Is this a bug, or are my man pages outdated?
Passing null to these functions constitutes undefined behavior according
to ANSI C. See clause 7.1.4 in the n843 draft of C99:
http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm
Outdated or not, your system's man pages don't define the language.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: glibc bug strtol
Date: Thu, 03 Aug 2000 13:43:09 -0700
strtol() returns error on parsing MAX_INT: 2 ^ 32 -1
char *endptr;
int num;
num = strtol("2147483647", &endptr, 10);
perror( "should be success");
tye4
------------------------------
From: <[EMAIL PROTECTED]>
Subject: eexpress patch
Date: Thu, 03 Aug 2000 21:28:18 GMT
I had significant problems using an EtherExpress 16 with the eexpress
driver. I know everyone already knows it's flaky on faster machines.. well,
yeah.. it worked on a 486DX2-80 and didn't work in a Pentium 133 8-).
This patch seems to fix it; I don't know what the speed was without
the patch (since it wouldn't stay up long enough.. the machine didn't crash
but the network connectivity went..) With the patch, it transmits
800-850K/sec, and receieves full speed.
There was already some code in place to shut the CU off while copying a
packet to be sent, and then turn it on when it's done. The comments say
this is so the card won't flake out running in 16-bit mode with things like
the Alpha (with a theory that it was because it uses 8-bit data transfers.)
Well, the Pentium 133 board uses a Intel 430VX, so I think it's safe to say
the CPU and motherboard chipset are not uses 8-bit transfers to the card
8-). An alternative to the below would be to throw in a "#define LOCKUP16 1"
at the top so this is the default, with a comment that it can be shut off on
slower machines.
Of course, it would be best to find out what the real problem is and
fix it, since I get the impression this card could transmit at full ethernet
speed if it did work right, but I'm not going to try it 8-). I tried to
compare it with some other 82586 drivers to see if one of them maybe
twiddled some bits in a different order or something,
and I could see enough to tell that most of the 82586 based card
drivers were written independently of each other so comparison was
unhelpful. Oh well 8-).
*** eexpress.c~ Mon Jun 19 15:30:58 2000
--- eexpress.c Wed Aug 2 21:37:24 2000
***************
*** 963,979 ****
{
struct net_local *lp = (struct net_local *)dev->priv;
unsigned short ioaddr = dev->base_addr;
- if (LOCKUP16 || lp->width) {
/* Stop the CU so that there is no chance that it
jumps off to a bogus address while we are writing the
pointer to the next transmit packet in 8-bit mode --
this eliminates the "CU wedged" errors in 8-bit mode.
(Zoltan Szilagyi 10-12-96) */
scb_command(dev, SCB_CUsuspend);
outw(0xFFFF, ioaddr+SIGNAL_CA);
- }
outw(lp->tx_head, ioaddr + WRITE_PTR);
outw(0x0000, ioaddr + DATAPORT);
--- 963,972 ----
***************
*** 1003,1016 ****
lp->tx_head += TX_BUF_SIZE;
if (lp->tx_head != lp->tx_reap)
netif_wake_queue(dev);
- if (LOCKUP16 || lp->width) {
/* Restart the CU so that the packet can actually
be transmitted. (Zoltan Szilagyi 10-12-96) */
scb_command(dev, SCB_CUresume);
outw(0xFFFF, ioaddr+SIGNAL_CA);
- }
lp->stats.tx_packets++;
lp->last_tx = jiffies;
}
--- 996,1005 ----
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Reply-To: [EMAIL PROTECTED]
Date: Thu, 03 Aug 2000 21:51:26 GMT
On Thu, 03 Aug 2000 13:43:09 -0700, tye4 <[EMAIL PROTECTED]> wrote:
>strtol() returns error on parsing MAX_INT: 2 ^ 32 -1
>
>char *endptr;
>int num;
>
>num = strtol("2147483647", &endptr, 10);
>perror( "should be success");
You forgot to set errno to zero. If you look in the C standard, you will find a
little blurb which says that library functions do not set errno to zero.
I tried the above snippet glibc 2.1.3 and it reported success.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: Kai Xu <[EMAIL PROTECTED]>
Subject: Re: linux device drivers info
Date: Thu, 03 Aug 2000 18:17:06 -0400
Where did you find the "Linux Kernel Module Programming Guide" ?
I searched the www.linuxdoc.org and couldn't find it.
Thanks
MJ Dainty wrote:
> On Wed, 2 Aug 2000, Rafael [iso-8859-1] Garc�a wrote:
>
> | There are anything as good as the book 'Linux Device Drivers' by
> | Alessandro Rubini in a non printed format?
>
> Depending on how much depth you want to go into, I've dug up the "Linux
> Kernel Module Programming Guide", which should be available from most
> LDP mirrors. In the concluding section, it has a link to a page that
> lists loads of kernel-related HOWTOs, including a set of 5 tutorials
> co-written by the aforementioned Alessandro Rubini.
>
> If anyone else can suggest some other on-line docs, I'd also appreciate
> a pointer...
>
> Matt
------------------------------
From: [EMAIL PROTECTED] (Daniel P. Katz)
Subject: Re: read() and directories
Date: 03 Aug 2000 18:23:05 -0400
[EMAIL PROTECTED] (Alexander Viro) writes:
> Not. Just that layout is fs-dependent and everyone got _very_
> seriously burnt back in '84 when everything and its mom got b0rken
> by switch to FFS - programs assumed that they could read() directory
> and use the result. Major breakage followed and it took years to
> fix. Nobody wants that kind of shit again, especially considering
> the current average clue and cultural background of people writing
> under Linux (too many DOS buffs with no friggin' idea of portablitiy
> got injected into the culture).
I don't quite follow this. I mean, I understand the problem of people
doing silly low level coding when they ought to be using a higher
level abstraction, but actively forbidding people to *see* how
something is physically implemented seems an extreme response. I
guess I just find the notion of a "completely undumpable" file to be
very un-UNIX-ish; I would think that the ability to see what bits a
file is made of is rather fundamental.
>
> >I think the best idea would be to hack the source of od. However keep in
>
> NOT. Don't *WHAM* add *WHAM* random features to basic utilities *WHAM*
> *WHAM* *WHAM*. Remember "should be doing one thing and doing it well"?
I agree that basic utilities should not be subject to creeping
featurism if at all possible, but in this case it would be restoring
part of od's original functionality. :-)
Seriously, though, there must be *some* way to examine a directory's
basic internal structure. The notion of "unreadable bits" gives me
the creeps.
Dan
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: read() and directories
Date: Thu, 03 Aug 2000 22:49:39 GMT
On 03 Aug 2000 18:23:05 -0400, Daniel P. Katz <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Alexander Viro) writes:
>
> > Not. Just that layout is fs-dependent and everyone got _very_
> > seriously burnt back in '84 when everything and its mom got b0rken
> > by switch to FFS - programs assumed that they could read() directory
> > and use the result. Major breakage followed and it took years to
> > fix. Nobody wants that kind of shit again, especially considering
> > the current average clue and cultural background of people writing
> > under Linux (too many DOS buffs with no friggin' idea of portablitiy
> > got injected into the culture).
>
> I don't quite follow this. I mean, I understand the problem of people
> doing silly low level coding when they ought to be using a higher
> level abstraction, but actively forbidding people to *see* how
> something is physically implemented seems an extreme response. I
> guess I just find the notion of a "completely undumpable" file to be
> very un-UNIX-ish; I would think that the ability to see what bits a
> file is made of is rather fundamental.
Dear Dan, IMHO you make a mistake equalling a directory to a
file. od -x can dump a file, but you have to define a "reading
a stream" to be meaningful on filesystem directories. Consider
an example of NFS, which may have directories generated out of
thin air on the fly.
If you "know" beforehand that a directory has a dumpable representation
on the media, you may read it from the underlying device. This is the
way e2fsck operates, for example. If you do not "know" that, e.g.
you are not on a disk based filesystem, a dumpable representation does
not even exist for directories, and therefore "od -x" is not defined.
I hope this explains why you cannot apply read(2) to directories.
--Pete
P.S. Yeah, I hacked to UNIX v6 in the years of linked list of free blocks
and have no regrets about gone abilities of read(2).
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Subject: Re: read() and directories
Date: Thu, 03 Aug 2000 22:50:52 GMT
In article <[EMAIL PROTECTED]>,
Daniel P. Katz <[EMAIL PROTECTED]> wrote:
>> >I think the best idea would be to hack the source of od. However keep in
>>
>> NOT. Don't *WHAM* add *WHAM* random features to basic utilities *WHAM*
>> *WHAM* *WHAM*. Remember "should be doing one thing and doing it well"?
>
>I agree that basic utilities should not be subject to creeping
>featurism if at all possible, but in this case it would be restoring
>part of od's original functionality. :-)
>
>Seriously, though, there must be *some* way to examine a directory's
>basic internal structure. The notion of "unreadable bits" gives me
>the creeps.
Just out of obscure and perverse curiosity - what would you expect
your enhanced "od" to dump out, if you happened to run it on
/net/foo/bar or on /proc, for example?
Quite simple, a "directory's basic internal structure" may simply not
exist, in the sense you're suggesting. Fundamentally and
philosophically, a directory is _not_ defined as a glob of bytes -
it's a more abstract entity. The fundamental operations which are
relevant to directories are those which are defined by the API - add
name/attributes, look up name / attributes, delete name, iterate
through names.
Now, certain filesystems may happen to implement a directory as a
bunch of data stored within a single specially-tagged file - ext2
does, FFS does. Other filesystems may implement a directory as two or
more inter-related files - I'm working on one now which implements a
directory as a B-tree of nodes, each node being a file of up to 8k
bytes. A few years ago I implemented a filesystem which implemented
the entire volume's entire filesystem tree in the form of a single
GDBM database, which used (parent_directory_id,name) as the key, and
(type,locationinfo) as the data in the record. NFS implements
directories via RPC calls which implement the abstract operations, and
leaves the server-side representation of the directory entirely
unspecified. I gather that ReiserFS implements the directory
structure as a B+ tree, _and_ will actually store file data in the
tree as well.
In other words, when you ask "What does the contents of this directory
looked at, when viewed as a sequence of bytes", you're asking whether
a dog has the Buddha-nature. The correct answer to your question is
"Mu!" - or "Don't ask that question!"
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: glibc bug?
Date: Thu, 03 Aug 2000 23:32:25 GMT
On Thu, 03 Aug 2000 13:14:31 -0700, tye4 <[EMAIL PROTECTED]> wrote:
> A NULL passed to strcmp() and similar functions causes segmentation
> fault:
>
> // crash
> strcmp( NULL, "something" );
> strcmp( "something", NULL );
>
> Is this a bug, or are my man pages outdated?
>
> tye4
This is to be expected, and my man pages do not say that NULL is
permitted. What system are you at and what man page do you mean?
--Pete
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Thu, 03 Aug 2000 16:53:33 -0700
strtol() sets errno to indicate that a number to too big or too small for an int.
try this:
char *endptr;
int num;
errno = 0; // doesn't matter what the value is; will always be set to 34, ERANGE
num = strtol("9999999999", &endptr, 10); // too big
perror("should be Out of Range (ERANGE)");
// uncomment next line for correct behaviour
// errno = 0;
num = strtol("5", &endptr, 10);
perror("should be success");
This is a bug. If a function uses errno to indicate failure, it should set it to 0
on success.
tye4
Kaz Kylheku wrote:
> You forgot to set errno to zero. If you look in the C standard, you will find a
> little blurb which says that library functions do not set errno to zero.
>
> I tried the above snippet glibc 2.1.3 and it reported success.
>
> --
> Any hyperlinks appearing in this article were inserted by the unscrupulous
> operators of a Usenet-to-web gateway, without obtaining the proper permission
> of the author, who does not endorse any of the linked-to products or services.
------------------------------
Date: Thu, 03 Aug 2000 17:49:28 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ntfs support in kernel 2.2.14?
Kent Bergelin wrote:
>
> Is there yet no ntfs support for Linux kernel 2.2? I was convinced there
> was.....
>
> There is an alpha patch at www.penguin.cz which claims itself to be "very
> buggy". Are there other resources to Your knowledge?
>
> My only need is to mount two local ntfs partitions.
Read-only support has worked for quite a while, which I've used on
various 2.2.x. The read/write is the one that is buggy and to use with
caution. You'll find the support in kernel compile options.
------------------------------
From: "Nikhil G. Daddikar" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.embedded
Subject: Can't get a framebuffer console
Date: Thu, 03 Aug 2000 17:00:11 -0700
Hi,
I am using the IBM 405GP (PowePC) board and running 2.4 version of
linux. I have a matrox card and was able to get the framebuffer working.
When linux boots up, I see the message "Console: switching to
framebuffer..." but I don't see anything on the monitor. The console
device is still the serial port. I don't quite understand how this all
works so any pointers would be helpful.
Thanks.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: read() and directories
Reply-To: [EMAIL PROTECTED]
Date: Fri, 04 Aug 2000 00:07:32 GMT
Centuries ago, Nostradamus foresaw a time when Daniel P. Katz would say:
>[EMAIL PROTECTED] (Alexander Viro) writes:
>
>> Not. Just that layout is fs-dependent and everyone got _very_
>> seriously burnt back in '84 when everything and its mom got b0rken
>> by switch to FFS - programs assumed that they could read() directory
>> and use the result. Major breakage followed and it took years to
>> fix. Nobody wants that kind of shit again, especially considering
>> the current average clue and cultural background of people writing
>> under Linux (too many DOS buffs with no friggin' idea of portablitiy
>> got injected into the culture).
>
>I don't quite follow this. I mean, I understand the problem of people
>doing silly low level coding when they ought to be using a higher
>level abstraction, but actively forbidding people to *see* how
>something is physically implemented seems an extreme response. I
>guess I just find the notion of a "completely undumpable" file to be
>very un-UNIX-ish; I would think that the ability to see what bits a
>file is made of is rather fundamental.
That's fine and dandy, but if you actually _use_ this for anything, it
ties you to a particular version of a particular filesystem.
>> >I think the best idea would be to hack the source of od. However keep in
>>
>> NOT. Don't *WHAM* add *WHAM* random features to basic utilities *WHAM*
>> *WHAM* *WHAM*. Remember "should be doing one thing and doing it well"?
>
>I agree that basic utilities should not be subject to creeping
>featurism if at all possible, but in this case it would be restoring
>part of od's original functionality. :-)
>
>Seriously, though, there must be *some* way to examine a directory's
>basic internal structure. The notion of "unreadable bits" gives me
>the creeps.
How should things vary if:
a) /usr/local is an ext2 filesystem, and you do "cat /usr/local"?
b) How about if /usr/local/myserver is an NFS mount, and you do "cat
/usr/local/myserver"?
c) And if you do "cat /coda/someserver"?
d) How about "cat /local/somereiserfsfs"?
e) And "cat /redundant/ext3fsnumber1"?
If you have 3 different kinds of filesystems around, that use
differing physical directory structures, portability disappears
without worrying about versioning.
With the NFS mounts, there's _nothing there to cat_.
/usr/local/myserver _isn't a file_, and the NFS protocol isn't
expected to pass back anything meaningful.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/>
"Another result of the tyranny of Pascal is that beginners don't use
function pointers." --Rob Pike
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
