> So, you want to write a program that shows users what block devices are currently available to them. Seems conceptually simple and potentially very useful. And, right off the bet you hit complexity: do loop devices count? Do separate partitions count, and if so, what to do about special partitions that keep data necessary for hardware RAIDs to function, that, in general, shouldn't be exposed to users)? How do you go about RAID devices, do you acknowledge that RAIDs exist and display them as separate entities, or do you pretend they don't and only display their constituents? How about physical and logical volumes? Do you think that you need to support ZFS volumes? What if some FUSE filesystem decides to expose some information as a device file, does that count as a block device? What about iSCSI (potentially with multipathing)? Encrypted devices?
I think PowerShell had right idea here, even if it maybe went too hard into "object oriented".
If tools had option to pass structured representation between eachother the above problem could be solved by tool that returns everything + set of generic tools to filter information, like say
lsblk | f(type=disk,bus=nvme,name != nvme0n1) # all physical nvme devices except nvme0n1
lsblk | f(type=lvm_lv,vg=data,mountpoint =~ {^/data} ) # any LVM LV that is in data VG and mounted under /data
I wonder if it would be possible to retrofit into existing design. Like, have additional filedescriptors and some way of signalling so shell can connect "structured out" with "structured in" of the next app in the pipe.
> And there are more... there's archaic NBD alongside with the blazing hot NVMe over IP and so on. And you don't really have any unifying interfaces. You can look into /sys/block, but depending on how you answered the questions above, you'll either find too little or too much info there. And there's not a single tool that can really, in all circumstances, give you a correct answer to the question "what block devices are currently available".
I'd be interested in which case lsblk is not showing block devices, so far it has been pretty bulletproof for me, even in extremely weird setups
Microsoft isn't at the place yet where they may possibly have this problem. They aren't making an operating system that's extendable by others, that needs to incorporate interests of others. Where anyone may come and take any part of the system and repurpose it to their need. They have the luxury of not having to coordinate with others. This takes away from the usefulness of their product (eg. I see no value for myself in using such an operating system), but it makes it easier in engineering terms to make one.
So, PowerShell doesn't solve the problem. It didn't have one from the start. But, it also has nothing to offer to the Linux world as a consequence. The problem we have in the Linux world is more of a people problem before it's an engineering problem. We need an authoritative body that can mediate the interests of many parties using the system, incorporate their wishes and workflows, and then design a generic and extensible way of using the system. Right now it's chaos and anarchy which hinder or prevent the creation of useful programs. PowerShell would only increase the entropy of the system.
> I'd be interested in which case lsblk is not showing block devices
What about device files in a FUSE system randomly mounted somewhere? Also, I don't know of any way of showing loop devices with lsblk. Also, lsblk doesn't show RAIDs as individual devices, it shows them piece-wise. Also, I'm not sure about how it integrates (if at all) with ZFS block devices (I think it does on FreeBSD though). From what I understand, lsblk will only show a (large) subset of what may be found in sysfs. If it's not there, it's not a block device from its standpoint.
I think PowerShell had right idea here, even if it maybe went too hard into "object oriented".
If tools had option to pass structured representation between eachother the above problem could be solved by tool that returns everything + set of generic tools to filter information, like say
I wonder if it would be possible to retrofit into existing design. Like, have additional filedescriptors and some way of signalling so shell can connect "structured out" with "structured in" of the next app in the pipe.> And there are more... there's archaic NBD alongside with the blazing hot NVMe over IP and so on. And you don't really have any unifying interfaces. You can look into /sys/block, but depending on how you answered the questions above, you'll either find too little or too much info there. And there's not a single tool that can really, in all circumstances, give you a correct answer to the question "what block devices are currently available".
I'd be interested in which case lsblk is not showing block devices, so far it has been pretty bulletproof for me, even in extremely weird setups