Bill Studenmund <wrstuden@netbsd.org> wrote:
>> > Why? We've always let the routines be global before. Why should we stop
>> > that now? Also, with the above change, you're doing more than just change
>> > how we handle b/cdevsw, you're forcing anything which calls routines
>> > directly to now have to know about major numbers. Also, you're forcing
>> > major numbers (for these rare cases) to have to be made global. :-)
>> >
>> > That strikes me as a bad thing.
>>
>> IMHO it means that the symobols don't HAVE to be global.
>> In some drivers they will be anyway because the routines will
>> be in different source files (unless you do clever things with ld).
>
>True. And that can be an advantage.

After my changes, all device interfaces is still global.
If really want to call them directly, do it.

>> > Just to make sure I understand, compiled-in drivers won't need
>> > devsw_attach(), correct?
>>
>> My reading was that this would have to be done somewhere.....
>> OTOH it could be magiced up by the build process.
>
>I think it needs to be "magiced" up. We have a lot of devices, and to
>require every one of them to call devsw_attach(), when we can instead
>autogen a config file that has the relevant info, seems wasteful.

devsw_{attach,detach} is used only in the LKM framework now.
I don't know the future.

>> > > dev_t devsw_chr2blk_dev(dev_t chrdev);
>> > >
>> > > Convert from character dev_t to block dev_t.
>> > > Return the valid dev_t (!= NODEV) on success. Otherwise return NODEV.
>> > >
>> > >
>> > > dev_t devsw_blk2chr_dev(dev_t blkdev);
>> > >
>> > > Convert from block dev_t to character dev_t.
>> > > Return the valid dev_t (!= NODEV) on success. Otherwise return NODEV.
>>
>> Are these routines possible?
>> Esp. if the cdevsw and bdevsw entries are added separately.
>
>See my suggested change to devsw_attach() below. This question is exacly
>why I suggested it. :-)

How about this?

int devsw_attach(const char *devname, const struct bdevsw *bdev, int *bmajor,
                 const struct cdevsw *cdev, int *cmajor);
void devsw_detach(const struct bdevsw *bdev, const struce cdevsw *cdev);
const struct bdevsw *bdevsw_lookup(dev_t dev);
const struct cdevsw *cdevsw_lookup(dev_t dev);
int bdevsw_lookup_major(const struct bdevsw *bdev);
int cdevsw_lookup_major(const struct cdevsw *cdev);

(should remove '_lookup'?)

And change API of LM_DEV of LKM.

Get rid of LM_DT_BLOCK/LM_DT_CHAR

lkm_dev structure like this:

struct lkm_dev {
        MODTYPE lkm_type;
        int     lkm_ver;
        const char *lkm_name;
        u_long  lkm_offset;
        const char *lkm_devname;
        const struct bdevsw     *lkm_bdev;
        int lkm_bdevmaj;
        const struct cdevsw     *lkm_cdev;
        int lkm_cdevmaj;
};

name <-> majors

Get rid of devnametobdevmaj, chrtoblktabl and chrtoblk().

struct devsw_conv {
        const char *d_name;
        int d_bmajor;
        int d_cmajor;
};

const char *devsw_conv_blk2name(int);
int devsw_conv_name2blk(const char *, char *, size_t);
dev_t devsw_conv_chr2blk(dev_t);
dev_t devsw_conv_blk2chr(dev_t);

The intial conversion table is generated by config(8).

(should remove '_conv'?)

>> I would suggest trying to save the device-name to device number
>> map somewhere in the root filesystem.  This could be loaded into
>> the kernel (probably) before any dynamic assignments are done
>> (at least any for optional drivers).  That way /dev wont need
>> rebuilding.
>
>Hmmm... That could be interesting. I think that should be a seperate
>change, but it could be cool.

The mapping table should be in filesystem or in kernel?

--- MAEKAWA Masahide
--- Key fingerprint = BC5E D8CB 816C 2CB5 8560  FDE3 6CB8 BF5D 8D50 F2EE