I'd like to open SD card as physical drive on Linux.
Somethink like:
CreateFile("PHYSICALDRIVE0",...)
On MS Windows.
How can I do it?
All devices are represented as files under the /dev directory. These files can be opened exactly like regular files, e.g. open(/dev/sdb, ...).
Disk-like devices are also symlinked in the directories /dev/disk/by-id/, /dev/disk/by-path, and /dev/disk/by-uuid, which makes it much easier to find to matching device file.
Type df, to list all your filesystems mounted or unmounted. Once you know its address(everything in Linux is a file, so it will look like /dev/sda# or something like that) you can mount it with the mount command:
mount /path/to/drive /folder/to/mount/to
You open the block device special file (typically something like /dev/sdb) and then you can read/write blocks from it.
The interface is not clearly documented, it is a bug that there is no block(4) man page.
The sd(4) man page does help a bit though. The ioctls described there are probably valid for (some) other block devices as well.
Nowadays nearly all block devices appear as a "scsi drive" regardless of whether they are actually attached by scsi or not. This includes USB and (most) ATA drives.
Finding the right device to open may be a big part of the problem though, particularly if you have hotplug devices. You might be able to interrogate some things in /sys to find out what devices there are.
Related
Is there an API to read the Open-Firmware device tree from userspace?
For example, reading /sys/firmware/fdt (flattened device tree)?
If not, is the file format published so a userspace application can read entries from the fdt?
This is easier than I first thought. On devices that support Open-Firmware, the linux kernel mounts it as a virtual filesystem at /proc/device-tree/.
In my case, on the systems I happened to be checking, this was a symbolic link to /sys/firmware/devicetree/base. But either way, walking through the files and directories in /proc/device-tree/ is relatively easy to do, regardless of the language.
After running BitBake on several different recipe files, BitBake generates a file of type '.hddimg'. I haven't been able to find a clear explanation on what this file is used for, the closest that I have found is some speculation on the mailing list here. The author Paul states that:
the image isn't an image of a regular bootable system drive, but is a "live
image" of a smaller system that can either boot the real system from a
virtualized file system in RAM whose image is read from a single file in the
first level, or it can install the real system to a different drive.
The 'bootimg.bbclass' is what generates the .hddimg, and in the opening comments it is written that:
A .hddimg file [is] an msdos filesystem containing syslinux, a kernel, an initrd and a rootfs image. These can be written to harddisks directly and also booted on USB flash disks (write them there with dd).
Which appears to corroborate with what Paul wrote, but still leaves a lot of ambiguity on how to go about booting from this file (at least to a greenhorn like me).
Well, the doc says "write them there with dd". So:
dd if=/path/to/your/hddimg of=/path/to/raw/usb/device
so, if you have the file as my.hddimg and the usb flash disk appears as /dev/sdg
dd if=/home/karobar/my.hddimg of=/dev/sdg
As it's name implies, it's an image, so needs to be written as such. The actual file system is inside of the rootfs file, which is similarly an image!
Once you have that on the usb stick, the usb stick itself should be bootable. Depending on what you're trying to do this may not be the easiest kind of output from bitbake to work with.
win Api
WINAPI GetVolumeInformation(
_In_opt_ LPCTSTR lpRootPathName,
_Out_opt_ LPTSTR lpVolumeNameBuffer,
_In_ DWORD nVolumeNameSize,
_Out_opt_ LPDWORD lpVolumeSerialNumber,
_Out_opt_ LPDWORD lpMaximumComponentLength,
_Out_opt_ LPDWORD lpFileSystemFlags,
_Out_opt_ LPTSTR lpFileSystemNameBuffer,
_In_ DWORD nFileSystemNameSize
);
Hello: I want to port windows api GetVolumeInformation to Linux.
Q1:Does Linux have the same function.
Q2:if not.
Q2.1 what is lpVolumeNameBuffer in linux(is /dev/sda1)? how can i get it in linux?
Q2.2 what is lpVolumeSerialNumber in linux(is )? i use ioctl get it.
struct hd_driveid id;ioctl(fd, HDIO_GET_IDENTITY, &id);
Q2.3 what is lpMaximumComponentLength in linux? how can i get it in linux?
Q2.4 what is lpFileSystemFlags in linux? how can i get it in linux?
Q2.5 what is lpFileSystemNameBuffer? how can i get it in linux?
If you have any good ideas I would really appreciate it.
Thanks!
Conceptually, linux doesn't have volumes in the same way that Windows does - linux has mount points, Windows has 'drive letters', for lack of a better term.
lpVolumeName is the friendly name of a mounted volume - for instance, my C: drive is labeled 'main_disk'. The point of this label is only to give a friendly name to the drive, and the label can change whenever the user decides to change it, and it does not affect the structure of the ultimate file system layout.
In linux, volumes are mounted as mount points, eg, the device referred to as /dev/sda2 might be mounted at the /var mount point. Here, /var is part of the file system, and thus, mount points determine the structure of the ultimate file system layout. This is not simply a friendly name for the user to give to their disk so that they can know what it is.
Linux and others do support something called disk labeling, but that's used to be able to refer to the disk using a stable name, instead of its device name, which could change if the hard drives are moved around in the computer. For instance, in FreeBSD, I could label my main hard drive root; when that hard drive is detected during boot up, i can instead refer to it as /dev/label/root and specify the mount point for it using that name. However, this is still being used to determine the ultimate structure of the file system - it's a functional dependency - and so the user can't change it willy-nilly without breaking something or having to change the fstab file that describes device-to-mount-point mappings.
lpVolumeSerialNumber has to do with the filesystem on the volume; that is, this field is specific to what filesystem is being used on the volume, and isn't something that all volumes will have.
In Windows, typically two filesystems are supported - Fat32 and NTFS - both of which can give a serial number to a file system. In Linux, FreeBSD, etc, there are many, many file systems - UFS/UFS2, EXT/EXT2/EXT3/EXT4, ReiserFS/Reiser4, BTRFS, ZFS, FFS, etc. Whether or not a volume has a serial number depends on what file system the volume is using, and not all filesystems support serial numbers. Each filesystem will have its own utility commands to query this sort of data - for instance, dumpfs on FreeBSD for UFS2 file systems.
The list goes on. Unfortunately, there are no direct analogs between Windows and Linux for the parts you're asking about, but as I've shown, sometimes it doesn't matter and when it does, you can usually find something to replace it with.
POSIX systems have statvfs()/fstatvfs() subroutines (which might be a library function or system call, depending on the OS). Perhaps they are what most closely resemble what the Windows' function you named does, but they have a very different interface.
I don't know if it matters to you, but a related problem is to enumerate mounted filesystems. To enumerate currently mounted filesystems on Linux, you can read the contents of /proc/mounts. Some other UNIX flavors (namely BSD-derived systems) have getvfsstat()/getfsstat() calls for the same purpose. Solaris has (or used to have) neither, and you best choice was to read /etc/mnttab. AIX has none of these, and your (only?) reliable (?) option to enumerate current mounts is to parse the output of the mount command, run without any argument.
if I plugin a USB memory stick, I see a new folder in /sys/bus/usb/devices ... thus a new USB-device.
Also I see a new folder in /sys/block ... thus a new block-device.
My question is: How can I get a waterproof mapping between those two devices? Means:
If I get a new device in /sys/bus/usb/devices, how can I programatically (f.i. by checking /sys/...) find out which block device is mapped/related to this usb-device and vice-versa?!
The information in /sys is organized in multiple ways (by driver, by bus, etc.), and there are many symbolic links to go from one hierarchy to another.
Case in point (example seen on kernel 2.6.26): starting from the block device in /sys/block/sdc, the symbolic link /sys/block/sdc/device points inside the per-device-type hierarchy. You can see that it's an USB device because the target of the link is something like
../../devices/pci0000:00/0000:00:1d.7/usb8/8-2/8-2:1.0/host9/target9:0:0/9:0:0:0
Conversely, USB devices are listed in /sys/bus/usb/devices, and we can see that 8-2:1.0 is a disk-like device because /sys/bus/usb/devices/8-2:1.0/driver links to usb-storage. To find out what the associated block device is, it seems we need to go down to the directory /sys/bus/usb/devices/8-2:1.0/host9/target9:0:0/9:0:0:0 which contains a symbolic link block:sdc whose target is /sys/block/sdc.
ADDED: Caution: the exact structure of /sys changes from kernel version to kernel version. For example, with kernel 2.6.32, /sys/block/sdc/device points directly into the /dev/bus/scsi without going through the USB hop.
A different approach is to call the udevadm info command. udevadm info -p /sys/block/sdc --query=… gives information on a device based on its /sys entry, while udevadm info -n sdc --query=… gives information on the device /dev/sdc.
The information includes bus information, for example udevadm info -p /sys/block/sdc --query=env shows
ID_BUS=usb
ID_PATH=pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0
The udev documentation may have more information of interest to you.
A final word of caution: there are all kinds of complex cases that may make whatever you do not so waterproof. How will your program deal with a single USB device that is an array of disks that are assigned multiple block devices? Conversely, how will your program deal with a RAID array assembled from multiple devices (perhaps some of them USB and some of them not)? Do you care about other removable media types such as Firewire and e-SATA? etc. You won't be able to predict all corner cases, so make sure to fail gracefully.
As far as I found out, it's possible to access udev information via "libudev" library. There's also a good sample on the net available: http://www.signal11.us/oss/udev/
I was able to modify it to read out all "/dev/sd*" devices and get their Vendor-ID, Product-ID as well as Serial number. I think this solution is kernel/linux distribution independant enough. But I still have to verify this.
I want to be able to inspect my Linux machine hardware in C.
How do I get the information that appear in dmesg in C ?
For example, for keyboard the message is input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
I want to get in my program the label, AT Translated Set 2, and the path, /devices/platform/i8042/serio0/input/input0.
Any idea how to do so ?
amit
You can also look at the contents of files in /proc.
/proc/version, /proc/ioports, /proc/iomem, /proc/meminfo, and others have a lot of information in them.
The files under /proc/bus have additional information about the system's hardware devices.
I'd also recommend looking at the source code for usbutils and pciutils for example code to get the output from the lsusb and lspci commands respectively.
It uses the klogctl call.
Best thing is to read the source code yourself, it can be downloaded here: util-linux
You would want to use libhal, and connect to the hal daemon. If HAL isn't there, look for a mounted sysfs partition. Check out /sys/devices, or work backwards through /sys/bus.
If neither HAL nor sysfs is available, reconsider your approach or restrict your scope.