dev_t / udev_t confusion ?

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 06/09/04

  • Next message: Brian Feldman: "Re: dev_t / udev_t confusion ?" 
    To: arch@freebsd.org
Date: Wed, 09 Jun 2004 13:16:30 +0200

    I have an item on my TODO list which says "fix dev_t / udev_t kernel
    confusion before 5-STABLE ?".

    The confusions is that in userland dev_t is an integer type which
    encodes the major+minor number of a device, in the kernel it it a
    pointer to "struct cdev" which represents the device to the kernel.

    Back when dev_t became a struct pointer, I counted the number of
    kernel source files which used the kernel dev_t vs the ones that used
    the useland dev_t and found something like 325:25.

    Since we share a number of device drivers with other OSs, and
    following the simple plurality, I called the userland dev_t "udev_t"
    in the kernel. And therefore, "dev_t" in userland and "dev_t" in
    the kernel are entirely different.

    We had a discussion about fixing this some point back, and I am not
    sure if we really reached closure on it.

    The change proposed is more or less to do:
            s/dev_t/struct cdev */
            s/udev_t/dev_t/
    over all the kernel sources (366 files or so).

    The benefit is that we get the dev_t/udev_t confusion solved, the
    disadvantage (apart from the churn) is that we reduce the already
    limited direct source compatibility with other BSDs a bit further.

    Personally I'm pretty 50/50 on this issue, but if we want to do it,
    we want to do it before 5-STABLE, not after (to avoid the FreeBSD3
    syndrome).

    Personally I don't think there is much need for a long discussion
    and I would prefer to see simply a show of hands for yes and no,
    and any hear any really heavy duty arguments pro et contra. 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Brian Feldman: "Re: dev_t / udev_t confusion ?"

    Relevant Pages

    • Re: [i2c] [RFC][PATCH 4/4] RTC: SMBus support for the M41T80,
      ... confusion amongst developers, ... rename only the kernel variants, ... we rename also the user-space variants, then it's up to 2.4 kernel ...
      (Linux-Kernel)
    • Re: epoll_ctl and const correctness
      ... there is a confusion, ... the structure isn't const? ... the kernel keep track of this structure, that is, it keeps a pointer ...
      (Linux-Kernel)
    • RE: kernel update/wireless install
      ... The exact output from uname -r gives: ... Hence the confusion. ... Subject: kernel update/wireless install ... Type uname -r it will tell you which kernel you are actually running, ...
      (Fedora)
    • Re: What are modules - (contd) ?
      ... confusion. ... I like to think of modules as building blocks that are ... used to build on the base (the kernel) to create new structures. ... device drivers. ...
      (Fedora)
    • Re: Attempted summary of "RT patch acceptance" thread
      ... tries to keep the userland API as close as possible to the non-RT one, ... by increasing the kernel complexity with relative slowdown. ... RTAI quickly becomes useless (ok it can run nanosleep with fusion fine, ... RTAI/rtlinux as the only hard-RT with guaranteed deadline. ...
      (Linux-Kernel)