From: "C. Linus Hicks" <lhicks@nc.rr.com>
To: linux-hotplug@vger.kernel.org
Subject: Assumptions in start_udev regarding the loop device
Date: Thu, 10 Feb 2005 06:25:18 +0000 [thread overview]
Message-ID: <1108016718.4753.86.camel@lh4.linush.net> (raw)
Okay, so as I was investigating the problem I am having and whether or
not it might be fixed in the latest version of udev, I am faced with the
fact that the issue I see is actually because of alterations Red Hat has
made. The thing is, I would guess they made the specific change I have a
problem with because of a perceived shortcoming of udev.
This is on a RHEL4 beta-2 system, which is using udev-039-6.
The Red Hat version alters start_udev in the make_extra_nodes function
adding a call to MAKEDEV to create loop0 - loop7 (among others). The
problem I have with this is that it takes no account for how many loop
devices are actually enabled in the system. If I add 'options loop
max_loop%6' to my modprobe.conf, when the system re-boots, I still get
only eight loop devices in /dev.
They have hard-coded the number of loop device files to make!?
I searched the archives, but I couldn't find any references to this
issue, so perhaps the udev developers don't perceive a problem? Is the
act of creating loop device files considered to be out of the scope of
the project? Red Hat's solution just happens to connect it there. So
because of my lack of clarity here, I have cross-posted this message.
At this point, I'm guessing a solution to the problem is not in the
works. I have altered my start_udev to 'MAKEDEV loop' so that it will
use /etc/makedev.d/linux-2.6.x to figure out how many to make. That
seems like a better, though imperfect solution. You only have to make
sure that your max_loop option value matches what's in makedev.d to get
the right number of loop device files.
A better solution would be to be able to query how many loop devices are
supported, but I haven't found a way to do this. And actually, shouldn't
this be handled at module load time, rather than system boot time?
(Isn't there a way to create device files when a module is loaded?)
Surely others are having this issue?
Suggestion to Red Hat: Don't hard-code eight loop devices. Change it to
use the value from makedev.d.
--
C. Linus Hicks <lhicks at nc dot rr dot com>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2005-02-10 6:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-10 6:25 C. Linus Hicks [this message]
2005-02-10 8:03 ` Assumptions in start_udev regarding the loop device Kay Sievers
2005-02-10 9:09 ` Marco d'Itri
2005-02-10 15:40 ` Harald Hoyer
2005-02-11 16:46 ` C. Linus Hicks
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=1108016718.4753.86.camel@lh4.linush.net \
--to=lhicks@nc.rr.com \
--cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).