[lkml]   [2001]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] struct char_device
    From Wed May 23 00:39:23 2001

On Tue, 22 May 2001 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.031 / U:1.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site