Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Do, 21.06.18 10:07, Adam Williamson (adamwill@xxxxxxxxxxxxxxxxx) wrote:

> On Thu, 2018-06-21 at 09:46 -0700, Gerald B. Cox wrote:
> > Interesting... thanks Adam... but the way I read that is specifically
> > tailored to "release criteria", not
> > design/implementation guidelines - i.e. to me this says, don't hold up a
> > release because someone
> > screwed up and didn't conditionalize the process correctly.
> 
> I think you're being a *bit* harsh, here, btw, constantly talking about
> how people are "screwing up". Conditionalized services are kind of an
> advanced systemd feature and many people probably don't know about them
> at all, and as we're discussing here, we *don't* actually have any
> requirement that services be conditionalized in this way. I don't think
> it's really fair to see this as packagers doing something horribly
> wrong and bad. (Also note that it's not at all straightforward to
> conditionalize some of these things in a reliable way - it seems
> Lennart had to add a new feature to systemd to aid in conditionalizing
> the secure boot-related service, and I don't think it'll be
> particularly straightforward to find a correct conditionalization for
> the rngd case either). It's just a situation we've identified where we
> could possibly improve things.

Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?

(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/MUYP7R5TWRWBABNT2F7QTXEMTK6ONYLW/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux