From: Wim Van Sebroeck <wim@iguana.be>
To: Jean Delvare <jdelvare@suse.de>
Cc: linux-watchdog@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: modalias char-major-10-130
Date: Fri, 5 Jul 2013 22:53:07 +0200 [thread overview]
Message-ID: <20130705205307.GB14258@spo001.leaseweb.com> (raw)
In-Reply-To: <1372854803.22042.22.camel@chaos.site>
Hi Jean,
> All watchdog drivers include:
>
> MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
>
> which causes a modalias char-major-10-130 to be added to every watchdog
> driver module. As a result, any access to /dev/watchdog on a system with
> no watchdog driver loaded and working will result in an attempt to load
> several dozen drivers. At best one or two will actually work, the others
> will:
>
> * Waste time failing to load.
> * Waste memory succeeding to load but not finding any device to bind to.
> * Pollute the kernel log.
> * Sometimes even load while they should not and break the system. I just
> had a report about advantechwdt doing that on some systems.
>
> And the attempt order will presumably be random, so it might as well
> load softdog before a hardware-based watchdog which would have been
> preferred.
>
> This looks so 90s. Drivers for enumerated devices have hardware-based
> modaliases, so char-major-10-130 shouldn't be needed. Other drivers
> should certainly not be loaded randomly if they need to poke the
> hardware to detect the presence of a supported device.
>
> My opinion is that the char-major-10-130 modalias should ONLY be defined
> by user-space, when the user knows he/she needs a watchdog driver which
> doesn't support auto-loading via hardware-based auto-loading.
>
> So, can we please get rid of all these
> MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR) statements? They do more harm than
> good as far as I can see.
You have a valid point: There were we have modaliases and other detection
mechanism we should indeed remove them. The rest should be evaluated
afterwards on a case by case basis. Certain intel based drivers should
(like advantechwdt) should indeed be fixed because they poke in the hardware
directly and can't be really detected.
Kind regards,
Wim.
next prev parent reply other threads:[~2013-07-05 20:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 12:33 Jean Delvare
2013-07-05 17:18 ` Guenter Roeck
2013-07-05 20:53 ` Wim Van Sebroeck [this message]
2013-10-21 12:36 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130705205307.GB14258@spo001.leaseweb.com \
--to=wim@iguana.be \
--cc=jdelvare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®