Strange echo behaviour

Peter Korsgaard jacmet at
Wed Jan 26 19:33:30 UTC 2011

>>>>> "Jim" == Cathey, Jim <jcathey at> writes:


 Jim> The 'errors' EBUSY and EAGAIN are _temporary_ conditions,
 Jim> often the correct response is to try again.  (Even EACCESS,
 Jim> ENOSPC, EEXIST, etc. could be considered temporary, depending
 Jim> on circumstances, and a delayed retry could be considered the
 Jim> right thing to do.  Not commonly, of course.)

Yes, in this case it means the GPIO is currently used for something

 Jim> Nowhere I know of is it required that a retry be exactly the same
 Jim> as a rejected attempt, one could even argue that trying it again a
 Jim> different way might even be superior under certain conditions.
 Jim> (Not, of course, when speaking to devices that have blocking
 Jim> requirements, whether advertised or unadvertised.)

Naturally, but because of how sysfs is implemented, writes have to be
atomic (data is copied to a kernel space buffer FOR EACH WRITE and
handed over to to the store handled for the attribute).

You can argue that the gpio export attribute should perhaps have
returned something more permanent, like EINVAL instead - But this is how
it has been done for years.

For both coreutils and bb echo, output is done to stdio. On what C
library (version) was the 1 char write seen? I did a quick test on
uClibc 0.9.31 and it behaves like expected:

strace -e write /bin/echo 179 >export 
write(1, "179\n", 4)                    = -1 EBUSY (Device or resource busy)
write(1, "179\n", 4)                    = -1 EBUSY (Device or resource busy)

 Jim> I still submit that if you are communicating with something
 Jim> that has a specific blocking requirement then _you_ are
 Jim> responsible for ensuring that you're using a tool that has
 Jim> control over the blocking.  DD is the main shell-level tool
 Jim> for that.

Still, all examples you'll see are with echo / cat, even if read/writes
must be atomic.

 Jim> I will also argue that though /proc and /sys were intended
 Jim> to offer the ease of using normal shell-level ops to control
 Jim> the system, the implementation of the drivers in the kernel
 Jim> is flawed if there are blocking requirements, especially
 Jim> since I've never seen mention anywhere in man pages that
 Jim> multi-byte writes must be atomic!

It's a core part of how sysfs is implemented, so it goes for ALL sysfs

Bye, Peter Korsgaard

More information about the busybox mailing list