[kernel] Rewrite block requests to use start sector and count rather than block number

[ghaerr]

Work in preparation to move track caching code out of bioshd driver, for use by other drivers.

All block drivers changed to receive requests in terms of sectors, allowing eventual use of a multi-sector I/O request for track caching or raw device I/O (without system buffers) with any block device driver.

Adds get_sector_size function allowing ll_rw_blk level to learn sector size based on device number. This is implemented using the renamed HDIO_GET_SECTOR_SIZE -> IOCTL_BLK_GET_SECTOR_SIZE ioctl on block drivers that support hardware sector sizes != 512.

Tested on SSD (/dev/ssd), ramdisk (/dev/rd0) and bios (/dev/fd0, /dev/hd) drivers.

[toncho11]

So this (several PRs) is all in preparation to add a generic HDD driver that does not use the BIOS?

[ghaerr]

So this (several PRs) is all in preparation to add a generic HDD driver that does not use the BIOS?

Possibly. At this time, the kernel and buffer system are being prepared to handle async I/O, and the SSD driver has been updated and works fairly well to simulate async I/O when CONFIG_ASYNCIO is selected. Maintaining a working and reliable system is key for ELKS. There are still a number of potential issues, as moving to async I/O increases the complexity of the buffer, block I/O and filesystem activities by quite a bit.

Maybe the BIOS should stay the default, but there should be a kernel compile option to replace the BIOS with a direct access driver. Is it doable on the level of source code? Hmm adding an abstraction over the BIOS or direct access will in itself add a delay. So all disk kernel calls should be grouped in one file and then there should be a BIOS and several disk versions (for several types of HDDs) of this file?

@Mellvik has got the direct FD and direct HD drivers working using async I/O, with FD fully interrupt-driven on his fork called TLVC, and it is quite interesting. There remain a number of considerations as to whether the system can run with a BIOS HD or FD driver and a direct driver, that remains to be seen. There aren't any delay issues regarding additional layers or abstractions, instead the kernel itself has never been exercised with the level of multitasking occurring when async I/O is enabled, and data corruption bugs are being found and exterminated.

So all disk kernel calls should be grouped in one file and then there should be a BIOS and several disk versions (for several types of HDDs) of this file?

I don't know just how compatible the direct FD or HD drivers are with the variety of controllers and hardware drives out there. @Mellvik is quite familiar with most of the older hardware and is working on that with TLVC.