linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* lseek() on entries in /proc/device-tree returns EINVAL
@ 2008-04-16 20:57 Timur Tabi
  2008-04-16 21:01 ` Scott Wood
  2008-04-16 21:09 ` Joakim Tjernlund
  0 siblings, 2 replies; 7+ messages in thread
From: Timur Tabi @ 2008-04-16 20:57 UTC (permalink / raw)
  To: linuxppc-dev

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?

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: lseek() on entries in /proc/device-tree returns EINVAL
  2008-04-16 20:57 lseek() on entries in /proc/device-tree returns EINVAL Timur Tabi
@ 2008-04-16 21:01 ` Scott Wood
  2008-04-16 21:09 ` Joakim Tjernlund
  1 sibling, 0 replies; 7+ messages in thread
From: Scott Wood @ 2008-04-16 21:01 UTC (permalink / raw)
  To: Timur Tabi; +Cc: linuxppc-dev

On Wed, Apr 16, 2008 at 03:57:59PM -0500, Timur Tabi wrote:
> 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?

Try fstat().

-Scott

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: lseek() on entries in /proc/device-tree returns EINVAL
  2008-04-16 20:57 lseek() on entries in /proc/device-tree returns EINVAL Timur Tabi
  2008-04-16 21:01 ` Scott Wood
@ 2008-04-16 21:09 ` Joakim Tjernlund
  2008-04-16 21:10   ` Timur Tabi
  1 sibling, 1 reply; 7+ messages in thread
From: Joakim Tjernlund @ 2008-04-16 21:09 UTC (permalink / raw)
  To: 'Timur Tabi', linuxppc-dev

> -----Original Message-----
> From: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org [mailto:linuxppc-dev-
> bounces+joakim.tjernlund=transmode.se@ozlabs.org] On Behalf Of Timur Tabi
> Sent: den 16 april 2008 22:58
> To: linuxppc-dev@ozlabs.org
> Subject: 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?

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: lseek() on entries in /proc/device-tree returns EINVAL
  2008-04-16 21:09 ` Joakim Tjernlund
@ 2008-04-16 21:10   ` Timur Tabi
  2008-04-16 21:13     ` Joakim Tjernlund
  0 siblings, 1 reply; 7+ messages in thread
From: Timur Tabi @ 2008-04-16 21:10 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: linuxppc-dev

Joakim Tjernlund wrote:

> 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.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: lseek() on entries in /proc/device-tree returns EINVAL
  2008-04-16 21:10   ` Timur Tabi
@ 2008-04-16 21:13     ` Joakim Tjernlund
  2008-04-16 21:16       ` Timur Tabi
  0 siblings, 1 reply; 7+ messages in thread
From: Joakim Tjernlund @ 2008-04-16 21:13 UTC (permalink / raw)
  To: 'Timur Tabi'; +Cc: linuxppc-dev

> -----Original Message-----
> From: Timur Tabi [mailto:timur@freescale.com]
> Sent: den 16 april 2008 23:11
> To: Joakim Tjernlund
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: lseek() on entries in /proc/device-tree returns EINVAL
> 
> Joakim Tjernlund wrote:
> 
> > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: lseek() on entries in /proc/device-tree returns EINVAL
  2008-04-16 21:13     ` Joakim Tjernlund
@ 2008-04-16 21:16       ` Timur Tabi
  2008-04-16 21:40         ` Joakim Tjernlund
  0 siblings, 1 reply; 7+ messages in thread
From: Timur Tabi @ 2008-04-16 21:16 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: linuxppc-dev

Joakim Tjernlund wrote:

> 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.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: lseek() on entries in /proc/device-tree returns EINVAL
  2008-04-16 21:16       ` Timur Tabi
@ 2008-04-16 21:40         ` Joakim Tjernlund
  0 siblings, 0 replies; 7+ messages in thread
From: Joakim Tjernlund @ 2008-04-16 21:40 UTC (permalink / raw)
  To: 'Timur Tabi'; +Cc: linuxppc-dev

> -----Original Message-----
> From: Timur Tabi [mailto:timur@freescale.com]
> Sent: den 16 april 2008 23:16
> To: Joakim Tjernlund
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: lseek() on entries in /proc/device-tree returns EINVAL
> 
> Joakim Tjernlund wrote:
> 
> > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-04-16 21:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-16 20:57 lseek() on entries in /proc/device-tree returns EINVAL Timur Tabi
2008-04-16 21:01 ` Scott Wood
2008-04-16 21:09 ` Joakim Tjernlund
2008-04-16 21:10   ` Timur Tabi
2008-04-16 21:13     ` Joakim Tjernlund
2008-04-16 21:16       ` Timur Tabi
2008-04-16 21:40         ` Joakim Tjernlund

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).