On Wed, 2006-02-22 at 15:43 -0500, linux-os (Dick Johnson) wrote: > On Wed, 22 Feb 2006, Martin Schlemmer wrote: > > > Hi, > > > > Not sure when it started, but 2.6.16-rc[1234] at least have problems > > with unbuffered read() and /proc/devices on my x86_64 box. I first > > picked it up with dmsetup that did not want to work properly built > > against klibc (glibc with fread() worked fine though, as it mmap()'d the > > file). > > > > Following code (from HPA and klibc mailing lists), when compiled and run > > with /proc/devices only reads the first two lines and then exits > > normally, where with any other file works as expected. > > > > ----- > > #include <stdlib.h> > > #include <stdio.h> > > #include <unistd.h> > > #include <fcntl.h> > > #include <errno.h> > > #include <sys/stat.h> > > > > int main(int argc, char *argv[]) > > { > > char c; > > int i, fd, rv; > > > > for ( i = 1 ; i < argc ; i++ ) { > > fd = open(argv[i], O_RDONLY); > > if ( fd < 0 ) { > > perror(argv[i]); > > exit(1); > > } > > > > while ( (rv = read(fd, &c, 1)) ) { > > if ( rv == -1 ) { > > if ( errno == EINTR || errno == EAGAIN ) > > continue; > > > > perror(argv[i]); > > exit(1); > > } > > putchar(c); > > } > > > > close(fd); > > } > > return 0; > > } > > ----- > > > > Output over here: > > > > ----- > > # ./readbychar.klibc /proc/devices > > Character devices: > > 1 mem > > # > > ----- > > Thanks, > > Martin Schlemmer > > If your code ever worked, it's probably because of some > fortuitous buffering in the 'C' runtime library. Not my code .. I just did a minimal hack to get it to build with klibc (klibc do not support fscanf(), so used fread() and sscanf() ..). > Most > of the 'read' code in drivers that have a /proc interface > is not designed for 1-character-at-a-time I/O. It's expected > that it will be accessed like `cat` or `more` or other > such tools access it, -- one read with 4096-byte buffer -- > > read(3, "MemTotal: 773860 kB\nMemFre"..., 4096) = 670 > write(1, "MemTotal: 773860 kB\nMemFre"..., 670) = 670 > Maybe, but the same code I posted works fine with any other file in /proc, and works fine on my small p3 server with 2.6.14. > The read code uses sprintf to write all the parameters to > a buffer, then it copies the parameters to the user. The > next read will return 0 for EOF and reset the interface > for the next access. > > If your code read /proc without any help from the 'C' runtime > library, you would read the same first character, every time > you attempted to read a character. Don't do that! Your code > should do (with some error-checking): > > fd = open(argv[1], O_RDONLY); > buffer = malloc(LEN); > read(fd, buffer, len); > puts(buffer); > > Also, something seems somewhat strange because it is not > commonplace to provide a mmap() interface to /proc file-system > capability in drivers and the /proc base code doesn't > provide memory-map capability at least on 2.6.15.4. So, > your reference to memory-mapping the file seems to be > incorrect. > Might have misread the strace there. Thanks, -- Martin Schlemmer
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: Problems with read() on /proc/devices with x86_64 system
- From: Jan Engelhardt <[email protected]>
- Re: Problems with read() on /proc/devices with x86_64 system
- References:
- Problems with read() on /proc/devices with x86_64 system
- From: Martin Schlemmer <[email protected]>
- Re: Problems with read() on /proc/devices with x86_64 system
- From: "linux-os \(Dick Johnson\)" <[email protected]>
- Problems with read() on /proc/devices with x86_64 system
- Prev by Date: Re: 2.6.16-rc4: known regressions
- Next by Date: Re: 2.6.16-rc4: known regressions
- Previous by thread: Re: Problems with read() on /proc/devices with x86_64 system
- Next by thread: Re: Problems with read() on /proc/devices with x86_64 system
- Index(es):