Messages in this thread | | | Date | Tue, 8 Dec 1998 17:56:33 +1100 | From | Richard Gooch <> | Subject | Re: many many loop devices & devfs |
| |
Peter J. Braam writes: > To summarize my question differently: how do I arrange that > MAJOR(dev) always gives me PETER_LOOP_MJR and not different values > when using more than 256 devices?
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/
| |