The simple answer is you can't. If you have more than 256 devices,
(and you use unique device numbers for each) then you are going to
have more than one major number. This is because of the 8 bit major
size.
> Setting the f_ops is not enough. Block devices are mostly used through
> the ll_rw_block function (from the readpage functions). This is in
> (drivers/block/ll_rw_blk.c). Looking at that routine, one sees that:
>
> The key function to be called is dev->request_fn -- where the latter
> already depends on MAJOR.
>
> These request functions are attached to devices in the following way.
> Every driver says:
>
> blk_dev[MAJOR_NR].request_fn = .......
Yes, I see which request function you mean now.
> Now let's follow the path down. Typically a read request starts with
> generic_readpage (fs/buffer.c). This calls brw_page with dev the
> inode->i_dev, which is the i_rdev field of the special file describing the
> block device on which the inode resides.
>
> This function sets up an array of buffers, in which the dev field is
> copied in. This array is then passed to ll_rw_block.
>
> So perhaps merely fixing ll_rw_block to interpret certain device numbers
> very differently from others when it comes to MAJOR is enough?
Well, that looks like a horrible hack to me. I wonder even if there is
any need to use the ll_rw_block code at all. There is no reason I can
think of why you can't implement a block device of your own, using
your own file_operations. Then you can ignore the device numbers and
instead use the file->private_data to distinguish between instances of
devices in a class.
An alternative would be to have a devfs call that would allow you to
allocate a device number from a specified range of major numbers. Then
you would need to fill in the blk_dev table for each major number you
got back.
In other words, if you ask for 1024 device numbers, you get back a
handle you can use for future allocations (each time you use the
handle you get a uniquely allocated device number from the block of
1024). You are also told which major numbers you got.
> ps: The pcmcia package is in need of a devfs update too. I didn't
> get a serial port anymore (perhaps merely a configuration error.)
Um, I thought that the PCMCIA serial port just sat on top of the
existing serial tty infrastructure, and hence would call
tty_register() or something like that, which in turn registers the
entry with devfs. Is that not happening?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/