From: "Kevin P. Fleming" <kpfleming@cox.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Some question about Udev
Date: Wed, 06 Aug 2003 17:09:56 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-106019035908026@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-106004529728260@msgid-missing>
Greg KH wrote:
>
> initramfs isn't freed from memory today :)
OK, well, that's different then..
>
> Yeah, I've thought about that. Hacking up a udevfs would be a piece of
> cake due to the libfs code in the kernel if it comes to that. Just a
> ramfs image that allows multiple mounts.
Here's another thought (somewhat off-topic for this list): I have been
considering implementing a sysfs "class" for filesystems. If something
like that existed, the tmpfs (or ramfs) filesystem "driver" could
expose information about each existing tmpfs instance, including some
sort of cookie. With the addition of a new mount option for the tmpfs
filesystem, it would be possible to specify a remount of that existing
tmpfs instance by passing in the cookie for the existing instance.
Another option would be to make this cookie appear in /proc/mounts,
which would certainly be quicker to implement than a new sysfs class.
Thoughts?
>
> It's a piece of cake to rebuild a udev database, as we can just walk the
> sysfs tree. So any "errors" or restarts is easy to handle.
Hmmm... I guess I was thinking about things like udev tracking hotplug
event sequence numbers and such, needing to remember more than just
"what exists in sysfs right now". I may have been reading too much
into the situation though.
>
> Ick, I'll just stick with tdb using "normal" files to store such a
> state. On restart, just rebuild the database. Actually, using tdb's
> "ram database" option will be the way to go.
Well, by "magic" I just meant normal files that the user wouldn't see.
Something like /dev/.udev_state.tdb that could just sit around in
case another udev instance needed it. Sorry for the poor terminology
choice there.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
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
prev parent reply other threads:[~2003-08-06 17:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-05 0:55 Some question about Udev Stanley Wang
2003-08-05 1:25 ` Kevin P. Fleming
2003-08-05 17:19 ` Greg KH
2003-08-05 18:09 ` Greg KH
2003-08-05 18:19 ` Kevin P. Fleming
2003-08-06 7:23 ` Greg KH
2003-08-06 17:09 ` Kevin P. Fleming [this message]
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=marc-linux-hotplug-106019035908026@msgid-missing \
--to=kpfleming@cox.net \
--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).