The 'errors' EBUSY and EAGAIN are _temporary_ conditions, often the correct response is to try again. (Even EACCESS, ENOSPC, EEXIST, etc. could be considered temporary, depending on circumstances, and a delayed retry could be considered the right thing to do. Not commonly, of course.) Nowhere I know of is it required that a retry be exactly the same as a rejected attempt, one could even argue that trying it again a different way might even be superior under certain conditions. (Not, of course, when speaking to devices that have blocking requirements, whether advertised or unadvertised.)
I still submit that if you are communicating with something that has a specific blocking requirement then _you_ are responsible for ensuring that you're using a tool that has control over the blocking. DD is the main shell-level tool for that. I will also argue that though /proc and /sys were intended to offer the ease of using normal shell-level ops to control the system, the implementation of the drivers in the kernel is flawed if there are blocking requirements, especially since I've never seen mention anywhere in man pages that multi-byte writes must be atomic! The fact that it doesn't often bite doesn't make it right! -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
