Messages in this thread |  | | Date | Wed, 23 May 2001 01:33:23 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: [PATCH] struct char_device |
| |
From torvalds@transmeta.com Wed May 23 00:39:23 2001
On Tue, 22 May 2001 Andries.Brouwer@cwi.nl wrote: > > The operations are different, but all bdev/cdev code is identical. > > So the choice is between two uglies: > (i) have some not entirely trivial amount of code twice in the kernel > (ii) have a union at the point where the struct operations > is assigned. > > I preferred the union.
I would much prefer a union of pointers over a pointer to a union.
Why? Because if you have a "struct inode", you also have enough information to decide _which_ of the two types of pointers you have, so you can do the proper dis-ambiguation of the union and properly select either 'inode->dev.char' or 'inode->dev.block' depending on other information in the inode.
I am not sure whether we agree or differ in opinion. I wouldn't mind
/* pairing for dev_t to bd_op/cd_op */ struct bc_device { struct list_head bd_hash; atomic_t bd_count; dev_t bd_dev; atomic_t bd_openers; union { struct block_device_operations_and_data *bd_op; struct char_device_operations_and_data *cd_op; } struct semaphore bd_sem; };
typedef struct bc_device *kdev_t;
and in an inode
kdev_t dev; dev_t rdev;
In reality we want the pair (dev_t, pointer to stuff), but then there is all this administrative nonsense needed to make sure that nobody uses the pointer after the module has been unloaded that makes the pointer a bit thicker.
And we should not depend on the "inode->dev.xxxx" pointer being valid all the time, as there is absolutely zero point in initializing the pointer every time somebody does a "ls -l /dev".
Yes, that is why I want to go back and have dev_t rdev, not kdev_t. The lookup is done when the device is opened.
Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |