DragonFlyBSD

there are two dependency systems in place:

1. the "old" one, using the DL_NEEDED entry in the ELF headers.

2. the "new" one, using linker sets.

loader does (2), the kernel does (1). required modules specified in the
source set (2), Makefile sets (1).

I personally think that (1) is the correct choice, but I'm open for
discussion. Maybe the nicest thing would be to use the sources and (2) to
generate (1).

cheers
simon

Thanks for this info. That clarifies things a bit. I focused on
implementing (2) in the kernel so far but I've got no strong opinion.
I'll try to grok (1).

Cheers,
Nicolas

Did you ever finish this?

Hello Simon,

2009/1/24 Simon 'corecode' Schubert (via DragonFly issue tracker)
<bugs@crater.dragonflybsd.org>:

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:

Did you ever finish this?

Sorry for the late answer. My home ADSL connexion is broken and I'm
quite busy at my day job.

The short answer is no.

I hacked the kernel-side module loading code to add dependency and I
had sth that worked at least in simple cases but needs lots of
cleanup. I didn't check complex cases like cycles in the dependencies
graph.

I also tried your approach which if my memory served well involved no
changes kernel-side but changes in the makefiles. I gave up because I
needed to dynamically generate part of the makefile and didn't know
how to do that (or if make supports this).

Cheers,
Nicolas

Mh, seems to work fine for me. What exactly is the problem and how can I
reproduce it?

I do the following and it works fine as one can see:

1. kldstat
   Id Refs Address Size Name
   1 4 0xc0100000 6bd840 kernel
   2 1 0xc07be000 68c14 acpi.ko
   3 1 0xd0894000 3000 null.ko
   19:18:41 :/usr/src devfs
2. kldload snd_hda
   19:18:44 :/usr/src devfs
3. kldstat
   Id Refs Address Size Name
   1 6 0xc0100000 6bd840 kernel
   2 1 0xc07be000 68c14 acpi.ko
   3 1 0xd0894000 3000 null.ko
   4 1 0xd34e0000 11000 snd_hda.ko
   5 1 0xd34f1000 1d000 sound.ko

2009/8/18 Alex Hornung (via DragonFly issue tracker)
<bugs@crater.dragonflybsd.org>:

Alex Hornung <ahornung@gmail.com> added the comment:

Mh, seems to work fine for me. What exactly is the problem and how can I
reproduce it?

Your test case below should have reproduced it. Maybe that was fixed
at some point.

I do the following and it works fine as one can see:

19:18:38 :/usr/src devfs

1. kldstat
   Id Refs Address    Size     Name
    1    4 0xc0100000 6bd840   kernel
    2    1 0xc07be000 68c14    acpi.ko
    3    1 0xd0894000 3000     null.ko
   19:18:41 :/usr/src devfs
2. kldload snd_hda
   19:18:44 :/usr/src devfs
3. kldstat
   Id Refs Address    Size     Name
    1    6 0xc0100000 6bd840   kernel
    2    1 0xc07be000 68c14    acpi.ko
    3    1 0xd0894000 3000     null.ko
    4    1 0xd34e0000 11000    snd_hda.ko
    5    1 0xd34f1000 1d000    sound.ko

_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue941>
_____________________________________________

Nicolas Thery wrote:

2009/8/18 Alex Hornung (via DragonFly issue tracker)
<bugs@crater.dragonflybsd.org>:

Alex Hornung <ahornung@gmail.com> added the comment:

Mh, seems to work fine for me. What exactly is the problem and how can I
reproduce it?

Your test case below should have reproduced it. Maybe that was fixed
at some point.

I do the following and it works fine as one can see:

19:18:38 :/usr/src devfs

1. kldstat
   Id Refs Address Size Name
   1 4 0xc0100000 6bd840 kernel
   2 1 0xc07be000 68c14 acpi.ko
   3 1 0xd0894000 3000 null.ko
   19:18:41 :/usr/src devfs
2. kldload snd_hda

snd_hda contains a makefile fragment to depend on sound.ko.

cheers
simon

so what is a good example?

2009/8/18 Alex Hornung (via DragonFly issue tracker)
<bugs@crater.dragonflybsd.org>:

Alex Hornung <ahornung@gmail.com> added the comment:

so what is a good example?

kldload smbfs

(it depends on libiconv.ko and another .ko)

afaik this is solved with corecode's module work.