Re: Problem in calling System call [sys_mknod] in Kernel Module.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 5 Oct 2004 08:22:55 +0100 (BST), Dinesh Ahuja
<mdlinux7@xxxxxxxxxxx> wrote:

> I am working on character device driver and want to
> take an advantage of automatic allocation of major
> number. Therefore what I want is that whenever the
> init_module is called, the major number allocated by
> calling register_chrdev should be passed as an
> argument to sys_mknod and the users should have device
> ready in /dev heirarchy and the user should not
> explicitly call mknod with the new allocated major
> number.

This is what udev is for, and previously also devfs. It has been done
in userspace properly using a daemon which handles device creation in
a portable way - so it's not worth re-inventing the wheel for just one
driver - but more to the point, it's icky and yucky doing this in a
driver.

> It seems to be a good approach rather that I print a
> allocated major number and tell someone to executed
> mknod command explicitly.

No. This is something that Linux Device Drivers 2 suggests that you do
(I'll get that wiki page up with notes) but there are better ways to
solve this problem that even that book touches upon with the use of
devfs. It's not the authors' faults because they do mention dynamic
device creation but have limited page real-estate to go in to it in
detail.

So please, spare the world from this implementation and rely upon the
user to have something sane to create devices for their use - by the
time you ship anything most of the major distributions will be using
udev (yes even Debian eventually) so it's not worth re-inventing the
wheel again.

Cheers,

Jon.

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux