On 6/25/09, Andreas Robinson <andr345@xxxxxxxxx> wrote:
> On Wed, 2009-06-24 at 23:52 +0100, Alan Jenkins wrote:
> But forking is really cheap on Linux, isn't it? The kernel will only
> allocate a task structure and copy a page table, AFAIK. The rest is
> copy-on-write. We still save the time spent launching a shell, parsing
> the command line and so on, and get a (crude) way of detecting
> dependency loops.
I wouldn't begrudge the performance. I just think it's a hack too
far. If there are too many memory leaks, or some "fatal" errors that
shouldn't be, I would prefer to fix them.
I don't mind if you want to write prototypes using fork(), and I will
happily to read them if invited. But I don't want to see this merged.
>> AFAICS softdeps aren't triggered by aliases in this implementation.
>> So they won't apply to modules loaded during udev startup ("coldplug"
>> aka udevadm trigger). They aren't triggered by normal deps either.
>> lt looks like they're not a strict replacement for install commands
>> which run modprobe - and they seem largely pointless.
>>
>> Do you have some examples where softdeps would be useful even with
>> these limitations? The idea is to replace existing install commands
>> (or avoid the need for new ones), right?
>
> Damn, I hoped you wouldn't notice. ;-) You're absolutely right. The
> current logic is something I hacked up without much thought to make the
> rest testable, hoping it would sort itself out eventually.
>
> I've been fretting over the top-level structural additions and changes
> that need to be done because I don't want to break anything or introduce
> subtle bugs. So, some design decisions have repeatedly been put aside
> for "later". (Which is now, apparently.)
Sorry!
> For example: since the various commands are used in different places
> (c.f alias and install) it would be logical and nice to separate the
> configuration-file parsing and per-module lookup. (This is how softdep
> should be handled at any rate, that fnmatch() call inside the parser was
> an afterthought.)
>
> However, the include command should be ripped out at the same time, but
> I'm not sure downstream has had enough time to move away from using it
> yet.
>
> If include has to stay in for now, I'd have to design something ugly to
> encode the tree formed by the include files. That "something" would be
> obsolete before it's ever used and then be removed again in a few
> months.
>
> It's things like this that I have trouble getting past ...
Yeah... I'm not sure what I can add here, I can follow your logic and
feel just as trapped by it :-). It sounds like you've gone about as
far as you can go with this prototype. You can either wait until its
ok to remove "include", or branch off, remove "include" yourself, and
maybe suffer merge conflicts etc.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
