Conversation
Jarkko Sakkinen
jarkko
Edited 15 days ago
Nothing too fancy but I created a program called "usb-factory" meant to run as daemon and burn pre-configured images as usb mass storage appears based on image file and some policy. it's meant for instance situation where you need to burn the same image to a bunch of sticks . Obivously it can IPC status of all ongoing parallel writing jobs in order to update some kind of e.g., "burning station kiosk UI" or whatever ;-)
It's in C. I tried Rust but with a lot of string buffer construction going on I have more easier time with overflows ;-) I.e. instead of some language baked policy I want to process string buffer as follows.
Overflow happens => mark and truncate
Then with the condition of overflow marked:
2. More writes => silently drop and success
3. Read => failure
4. Check-and-read => success (as after checking it is cool to read trunacted result as you probably know why you need it).
With these cheap deferred failure semantics I can *design* the reaction to those overflow errors, and make their occurence deterministic. If you have a task manager there's just so much of doing some crazy things small strings and forwarding them as basis of comms so you really need to start to think it as a problem by itself ;-)
It's in C. I tried Rust but with a lot of string buffer construction going on I have more easier time with overflows ;-) I.e. instead of some language baked policy I want to process string buffer as follows.
Overflow happens => mark and truncate
Then with the condition of overflow marked:
2. More writes => silently drop and success
3. Read => failure
4. Check-and-read => success (as after checking it is cool to read trunacted result as you probably know why you need it).
With these cheap deferred failure semantics I can *design* the reaction to those overflow errors, and make their occurence deterministic. If you have a task manager there's just so much of doing some crazy things small strings and forwarding them as basis of comms so you really need to start to think it as a problem by itself ;-)
1
0
0
In this small (last 1.5 weeks it took me) but fun little project I spent a lot of time on getting this right:
Press Ctrl+C to exit.
event=device_detected device=/dev/sda
event=job_started device=/dev/sda
event=job_finished device=/dev/sda result=detached
I.e. distinguishing IO error and detachment ;-) it does have the personal computer user story when you unmount etc. but instead sticks randomly coming and going so getting these right is at least useful when analysing any failure situations. jobs run on io_uring's and uevents through netlink socket bring like the other part of context information.
Press Ctrl+C to exit.
event=device_detected device=/dev/sda
event=job_started device=/dev/sda
event=job_finished device=/dev/sda result=detached
I.e. distinguishing IO error and detachment ;-) it does have the personal computer user story when you unmount etc. but instead sticks randomly coming and going so getting these right is at least useful when analysing any failure situations. jobs run on io_uring's and uevents through netlink socket bring like the other part of context information.
1
0
0
As an extension to the current functionality i'd like at recording of USB devices so that you could check optionally for a stick does it have a working image (i.e. record success, IO error and detachment) e.g., for weird situations, i.e. have knowledge base which of the sticks are faulty and which can be safely shared or at least to the best of knowledge.
0
0
0