All of lore.kernel.org
 help / color / mirror / Atom feed
* question about raw(1)
@ 2016-07-04 13:39 Ruediger Meier
  2016-07-05 18:32 ` Dale R. Worley
  0 siblings, 1 reply; 5+ messages in thread
From: Ruediger Meier @ 2016-07-04 13:39 UTC (permalink / raw)
  To: util-linux

Hi,

I'm just curious, would this always work?: 

  modprobe raw
  raw /dev/raw/raw1 /dev/xyz

or should you wait for /dev/raw/rawctl after modprobe (udevadm settle or 
sleep)?

cu,
Rudi

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question about raw(1)
  2016-07-04 13:39 question about raw(1) Ruediger Meier
@ 2016-07-05 18:32 ` Dale R. Worley
  2016-07-07 20:27   ` Karel Zak
  0 siblings, 1 reply; 5+ messages in thread
From: Dale R. Worley @ 2016-07-05 18:32 UTC (permalink / raw)
  To: Ruediger Meier; +Cc: util-linux

Ruediger Meier <sweet_f_a@gmx.de> writes:
> I'm just curious, would this always work?: 
>
>   modprobe raw
>   raw /dev/raw/raw1 /dev/xyz
>
> or should you wait for /dev/raw/rawctl after modprobe (udevadm settle or 
> sleep)?

Interesting -- the modprobe manual page doesn't state explicitly whether
or not the module initialization actions will be completed before
modprobe returns.

Dale

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question about raw(1)
  2016-07-05 18:32 ` Dale R. Worley
@ 2016-07-07 20:27   ` Karel Zak
  2016-07-07 23:01     ` Ruediger Meier
  0 siblings, 1 reply; 5+ messages in thread
From: Karel Zak @ 2016-07-07 20:27 UTC (permalink / raw)
  To: Dale R. Worley; +Cc: Ruediger Meier, util-linux

On Tue, Jul 05, 2016 at 02:32:24PM -0400, Dale R. Worley wrote:
> Ruediger Meier <sweet_f_a@gmx.de> writes:
> > I'm just curious, would this always work?: 
> >
> >   modprobe raw
> >   raw /dev/raw/raw1 /dev/xyz
> >
> > or should you wait for /dev/raw/rawctl after modprobe (udevadm settle or 
> > sleep)?

This is generic problem and I don't think for utils like raw(8) is
there any elegant way how to wait for rawctl node. 

IMHO the right solution is write robust scripts and expect "bad things" 
from your OS :-)

> Interesting -- the modprobe manual page doesn't state explicitly whether
> or not the module initialization actions will be completed before
> modprobe returns.

Well, module initialization may also trigger uevent and the rest is
userspace (udev) business. In this case things are completely out of
kernel+modprobe control, so "module initialization done" is irrelevant
information.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question about raw(1)
  2016-07-07 20:27   ` Karel Zak
@ 2016-07-07 23:01     ` Ruediger Meier
  2016-07-08  0:30       ` Bernhard Voelker
  0 siblings, 1 reply; 5+ messages in thread
From: Ruediger Meier @ 2016-07-07 23:01 UTC (permalink / raw)
  To: Karel Zak; +Cc: Dale R. Worley, util-linux

On Thursday 07 July 2016, Karel Zak wrote:
> On Tue, Jul 05, 2016 at 02:32:24PM -0400, Dale R. Worley wrote:
> > Ruediger Meier <sweet_f_a@gmx.de> writes:
> > > I'm just curious, would this always work?:
> > >
> > >   modprobe raw
> > >   raw /dev/raw/raw1 /dev/xyz
> > >
> > > or should you wait for /dev/raw/rawctl after modprobe (udevadm
> > > settle or sleep)?
>
> This is generic problem and I don't think for utils like raw(8) is
> there any elegant way how to wait for rawctl node.
>
> IMHO the right solution is write robust scripts and expect "bad
> things" from your OS :-)

Yep, this was not a bug report. Just want to know how to write the 
script right.

It's about this openSUSE init script pull request
https://build.opensuse.org/request/show/405725

He removed the existing "sleep 2" after modprobe but I guess somebody 
had added that sleep for a good reason in past. Of course sleep is 
ugly, maybe "udevadm settle" would work too!? I simply don't know if 
udev or sleep would have any affect here at all. When testing locally 
the thing always works without any sleep. But this may not mean 
anything (as I've learned from ul test suite issues).

> > Interesting -- the modprobe manual page doesn't state explicitly
> > whether or not the module initialization actions will be completed
> > before modprobe returns.
>
> Well, module initialization may also trigger uevent and the rest is
> userspace (udev) business. In this case things are completely out of
> kernel+modprobe control, so "module initialization done" is
> irrelevant information.
>
>     Karel



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question about raw(1)
  2016-07-07 23:01     ` Ruediger Meier
@ 2016-07-08  0:30       ` Bernhard Voelker
  0 siblings, 0 replies; 5+ messages in thread
From: Bernhard Voelker @ 2016-07-08  0:30 UTC (permalink / raw)
  To: Ruediger Meier, Karel Zak; +Cc: Dale R. Worley, util-linux

On 07/08/2016 01:01 AM, Ruediger Meier wrote:
> It's about this openSUSE init script pull request
> https://build.opensuse.org/request/show/405725
> 
> He removed the existing "sleep 2" after modprobe but I guess somebody 
> had added that sleep for a good reason in past. Of course sleep is 
> ugly, maybe "udevadm settle" would work too!? I simply don't know if 
> udev or sleep would have any affect here at all. When testing locally 
> the thing always works without any sleep. But this may not mean 
> anything (as I've learned from ul test suite issues).

maybe use timeout(1) instead of waiting the full 2 seconds?

  timeout 2 sh -c 'while [ ! -e /dev/raw/$rawdev ]; do sleep .1; done'

Still pretty ugly, but performs better. ;-)

Have a nice day,
Berny

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-07-08  0:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-04 13:39 question about raw(1) Ruediger Meier
2016-07-05 18:32 ` Dale R. Worley
2016-07-07 20:27   ` Karel Zak
2016-07-07 23:01     ` Ruediger Meier
2016-07-08  0:30       ` Bernhard Voelker

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.