>>>>> "Jim" == Cathey, Jim <[email protected]> writes:
Hi, 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 else. 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 attributes. -- Bye, Peter Korsgaard _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
