On Mon, Mar 10, 2025, at 10:35 AM, Zdenek Kabelac wrote: > Dne 09. 03. 25 v 17:00 Zack Weinberg napsal(a): >> I am developing a device-mapper client library in Rust. [...] > While you could surely interface kernel directly through ioctl(), > you should probably base your tool around libdevmapper as this library > is there to solve version differences or possible kernel or udev > issue that pops up here and there - if you will go your own path, > you will need to reimplement these things within Rust - which > might potentially be problematic - as we are solving i.e. udev trouble > to be working only within our 'small world' across different version of kernel > and udev version installed on the system. Unfortunately this is not an option for me, as my library needs to be usable in a context where neither the base C library nor udev is available. > Again - you are free to reimplement your Rust version - but eventually this > may lead to a completely different set of udev rules needed for management of > Rust devices - as libdevmapper is free to 'change' DM udev rules as long as > we are 'internally' consistent - as these rules are seen as 'internal' > property for DM world. I don't immediately see how that could happen, can you be more specific about the potential problems you have in mind? > Device name and UUID are always plain 7bit ASCII. Is that enforced by the kernel, and if so, where? I was not able to find any code in the kernel that does that, but I could easily have missed it. > But there is a catch in udev process - as udev has even further limited char > subset usable for device names - libdevmapper uses name mangling for those. Thanks, this is helpful. Do you happen to know offhand where udev documents its character restrictions? How about target names, table parameters, and target message strings? What are the restrictions on those? zw
