lseek() on entries in /proc/device-tree returns EINVAL
I'm writing a utility that parses the device tree in /proc/device-tree, and in order to read a property into memory, I have to first find out how large it is.
So I have the following code:
off_t off;
int f;
f = open(filename, O_RDONLY);
if (f == -1) {
perror(__func__);
return NULL;
}
off = lseek(f, 0, SEEK_END);
if (off == -1) {
perror(__func__);
goto fail;
}The lseek() call returns -1, and errno is set to EINVAL. According to the man page, this means:
EINVAL The whence argument is not a proper value, or the resulting
file offset would be negative for a regular file, block special file, or directory.
Is there a limitation for the implementation of /proc/device-tree that prevents lseek() from working? If so, how do I determine the size of a property?
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 2 lines · Timur Tabi
Is there a limitation for the implementation of
/proc/device-treethat preventslseek()from working? If so, how do I determine the size of a property?
Try fstat().
-Scott
Quoted 29 lines
-----Original Message-----
From: [email protected] [mailto:linuxppc-dev- [email protected]] On Behalf Of Timur Tabi
Sent: den 16 april 2008 22:58
To: [email protected]
Subject:lseek()on entries in/proc/device-treereturns EINVALI'm writing a utility that parses the device tree in
/proc/device-tree, and in order to read a property into memory, I have to first find out how large it is.
So I have the following code:off_t off; int f; f = open(filename, O_RDONLY); if (f == -1) { perror(__func__); return NULL; } off = lseek(f, 0, SEEK_END); if (off == -1) { perror(__func__); goto fail; }The
lseek()call returns -1, and errno is set to EINVAL. According to the man page, this means:
Quoted 6 lines
EINVAL The whence argument is not a proper value, or the resulting
file offset would be negative for a regular file, block special file, or directory.Is there a limitation for the implementation of
/proc/device-treethat preventslseek()from working? If so, how do I determine the size of a property?
Yeah, just reported a similar problem at LKML. busybox start-stop-daemon broke between 2.6.23 and current tree. The change was intentional but the borkage was not. Al Viro has been informed, lets see what comes of it.
Jocke
Quoted 3 lines · Joakim Tjernlund
Yeah, just reported a similar problem at LKML. busybox start-stop-daemon broke between 2.6.23 and current tree. The change was intentional but the borkage was not. Al Viro has been informed, lets see what comes of it.
I've changed my code to use fstat() instead, which is better for my purposes anyway.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 7 lines
-----Original Message-----
From: Timur Tabi [mailto:[email protected]]
Sent: den 16 april 2008 23:11
To: Joakim Tjernlund
Cc: [email protected]
Subject: Re:lseek()on entries in/proc/device-treereturns EINVAL
Quoted 7 lines
Quoted 3 lines · Joakim Tjernlund
Yeah, just reported a similar problem at LKML. busybox start-stop-daemon broke between 2.6.23 and current tree. The change was intentional but the borkage was not. Al Viro has been informed, lets see what comes of it.
I've changed my code to use
fstat()instead, which is better for my purposes anyway.
Good, bb should probably do the same. I just hope Al will allow a grace period and restore the old behavior so bb can catch up.
Jocke
Quoted 2 lines · Joakim Tjernlund
Good, bb should probably do the same. I just hope Al will allow a grace period and restore the old behavior so bb can catch up.
I don't see any reason why lseek() should not always work. Besides, a "grace period" would mean that on some future kernel, older busybox will not work.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 7 lines
-----Original Message-----
From: Timur Tabi [mailto:[email protected]]
Sent: den 16 april 2008 23:16
To: Joakim Tjernlund
Cc: [email protected]
Subject: Re:lseek()on entries in/proc/device-treereturns EINVAL
Quoted 7 lines
Quoted 2 lines · Joakim Tjernlund
Good, bb should probably do the same. I just hope Al will allow a grace period and restore the old behavior so bb can catch up.
I don't see any reason why
lseek()should not always work. Besides, a "grace period" would mean that on some future kernel, older busybox will not work.
Sure, but better a grace period than none at all. Currently no bb works but with a grace period you can at least tell users to upgrade bb when the grace period is over.
Jocke