On Thu, Sep 15, 2011 at 10:58 AM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <jo...@antarean.org> wrote:
>> On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
>>> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <jo...@antarean.org>
>> wrote:
>>> >> I'm not entirely convinced this is the case, because it feels like
>>> >> some situations like network devices (nbd, iSCSI) or loopback would
>>> >> require userland tools to bring up once networking is up.
>>> >
>>> > Yes, but the kernel-events referencing those devices won't appear untill
>>> > after the networking is brought up.
>>> > The scripts that "udev" starts are run *after* a device-event is
>>> > created. If the device itself has not been spotted by the kernel (for
>>> > instance, the networking doesn't exist yet), the event won't be
>>> > triggered yet.
>>> >
>>> > This situation does not require udev to start all these tools when
>>> > network- devices appear.
>>> >
>>> > I hope the following would make my thoughts a bit clearer:
>>> >
>>> > 1) kernel boots
>>> >
>>> > 2) kernel detects network device and places "network-device-event" in
>>> > the
>>> > queue
>>> >
>>> > 3) further things happen and kernel places relevant events in the queue
>>> > (some other events may also already be in the queue before step 2)
>>> >
>>> > 4) udev starts and starts processing the queue
>>> >
>>> > 5) For each event, udev creates the corresponding device-entry and
>>> > places
>>> > action-entries in a queue
>>> >
>>> > 6) system-init-scripts mount all local filesystems
>>> >
>>> > 7) udev-actions starts (I made up this name)
>>> >
>>> > 8) udev-actions processes all the entries in the action-queue
>>> >
>>> > From step 4, udev will keep processing further events it gets, which
>>> > means that if any action taken by "udev-actions" causes further devices
>>> > to become available, "udev" will create the device-entries and place
>>> > the action in the action-queue.
>>>
>>> So, if I read this correctly, there are two classes of processing
>>> events. kernel events and scripted actions. Here's rough pseudocode
>>> describing what I think you're saying. (Or perhaps what I'm hoping
>>> you're saying)
>>>
>>> while(wait_for_event())
>>> {
>>> kevent* pkEvent = NULL;
>>> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>>> waiting {
>>> process_kernel_event(pkEvent);
>>> }
>>> else
>>> {
>>> aevent* pAction = NULL;
>>> if(get_waiting_action(pAction)) // Returns true if there's an
>>> action waiting.
>>> {
>>> process_action(pAction);
>>> }
>>> }
>>> }
>>
>> This is, sort-of, what I feel should happen. But currently, in pseudo-code,
>> the following seems to happen:
>> while(wait_for_event())
>> {
>> kevent* pkEvent = NULL;
>> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>> waiting {
>> process_kernel_event(pkEvent);
>> }
>> }
>>
>> I would prefer to see 2 seperate processes:
>>
>> --- process 1 ---
>> while(wait_for_event())
>> {
>> kevent* pkEvent = NULL;
>> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
>> waiting
>> {
>> action_event = process_kernel_event(pkEvent);
>> if (action_event != NULL)
>> {
>> put_action_event(pkEvent);
>> }
>> }
>> }
>>
>> ------
>>
>> --- process 2 ---
>> while(wait_for_event())
>> {
>> aevent* paEvent = NULL;
>> if(get_waiting_action_event(paEvent)) // returns true if an event was
>> waiting
>> {
>> process_action_event(paEvent);
>> }
>> }
>> -------
>>
>>> So, udev processes one event at a time, and always processes kernel
>>> events with a higher priority than resulting scripts. This makes a
>>> certain amount of sense; an action could launch, e.g. nbdclient, which
>>> would cause a new kernel event to get queued.
>>
>> Yes, except that udev ONLY handles kernel-events and doesn't process any
>> "actions" itself.
>> These are placed on a seperate queue for a seperate process.
>>
>>> > If anyone has a setup where /usr can not be mounted easily, it won't
>>> > work
>>> > currently either and a init* would be necessary anyway.
>>> > (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting
>>> > /usr or other required filesystems)
>>>
>>> I don't see how this is relevant to actually fixing udev. (See below)
>>>
>>> > But anyone with a currently working environment should be able to expect
>>> > a currently working environment. If it fails to boot with only updating
>>> > versions, it's a regression. And one of the worst kinds of all.
>>>
>>> I agree that the direction udev is going is a regression. There aren't
>>> very many people active in this thread who would disagree with that
>>> point. So let's just drop it and focus on what a good, general
>>> solution would look like. (And anyone who says something amounting to
>>> 'status quo' for udev needs another explanation of why the udev
>>> developer sees the current scenario as broken. And he's right; the
>>> current scenario is architecturally unsound. I just think he's wrong
>>> about the solution.)
>>
>> I agree he is wrong about the solution as well.
>>
>> I have actually just posted my idea to the gentoo-dev list to see how the
>> developers actually feel about possible splitting udev into 2 parts.
>>
>> I'm not a good enough programmer to do this myself. But if anyone who can
>> code
>> and who also agrees with me that my idea for a solution is actually a good
>> idea, please let me know and lets see how far we can get with implementing
>> this solution.
>
> Now we are talking. I am really, *REALLY* interested to know the devs
> saying in the matter.
(This mail is to keep the guys un -user in the loop about -devel).
OK, so Joost posted his proposal to -dev:
http://archives.gentoo.org/gentoo-dev/msg_21e5b8c030cda26c5b317a0e3d9fad67.xml
Zac (portage maintainer, if you need to know) answered:
“Like it or not, it's the simplest possible solution if you want separate
/usr. The plan is to provide a minimal initramfs that won't contain any
modules, so it won't have to be rebuilt for each kernel. See the "/usr
vs. initramfs redux" thread:
http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml”
Joost asked for details about the Gentoo-sponsored minimal initramfs,
and Zac responded. Read the thread for the whole deal (Zac last
response is not up yet in the archive, should be in a couple hours I
think). I want to focus in how Zac closes his last mail:
“[Joost says]> If someone can explain to me why my idea won't work,
please let me know.
If your goal is to expose yourself to the possibility of unsatisfied
dependencies, they your idea will achieve it.”
Zac's answer is only true in the general case. But he (along with the
rest of the Gentoo devs) is responsible for a *whole* distro. The
important case is the general case. And in the general case, an
initramfs it's the only rational solution.
Zac does not speak for all of the Gentoo devs, of course. But the ones
opposing the idea cannot do much about it, if the ones actually
implementing it write the necessary code. The only alternative is to
write a fork of udev, like Joost is planning.
I would also like to point you guys to this article in LWN.net:
http://lwn.net/SubscriberLink/458789/3ae00c9827889929/
The article (the second part about systemd) closes with:
“The overall picture was of a project that is on a roll, gaining
features and users at a fast rate. The Systemd view of the world has
not yet won over everybody, but the opposition seems to be fading.
Systemd looks like the init system of the future (and more) for a lot
of high-profile distributions.”
The article was written by Jonathan Corbet, editor of LWN and (I think
most people would agree with me) someone who has always tried to be
objective and impartial.
So, if Joost and others are willing and able to implement the
necessary bits to avoid the need for an initramfs, I salute them and
wish them luck. But the most probable outcome is this:
* The fork/replacement will take years of man-effort: design,
implementation, debug, documentation, mainteinance.
* At the same time, the dev-approved solution of a minimal initramfs
or a dracut/genkernel generated one will be available and working.
* If the forking/replacement team manages to create a workable
fork/replacement, it will have to sell it to the Gentoo devs, and if
the initramfs solution is working properly the most rational answer
will be "no, thank you".
I'm sorry if my analysis bother some people, but it's basically what
I've been saying from the beginning. I'm glad Joost asked the
developers for their input. I think it clears the air about a lot of
things.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
