Re: Custom kernel builds failing w/undeclared identifiers?

[christos%astron.com@localhost (Christos Zoulas)]

In article <19603.1511418621%andromeda.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Thu, 23 Nov 2017 00:05:42 -0600 (CST)
>    From:        "John D. Baker" <jdbaker%mylinuxisp.com@localhost>
>    Message-ID:  <Pine.NEB.4.64.1711222356440.2947%david.technoskunk.fur@localhost>
>
>  | I'll try rolling this change back and seeing if that works.  I'm puzzled
>  | by what about my configs is confusing it, though.
>
>You'll need to send us (by which I mean the royal us, that is,
>christos%netbsd.org@localhost  (or the list if it is not secret)) a copy
>of a failing config file if this problem is to be found.
>
>  | This change fixed the infinite loop problem.  My last successful build
>  | was just after this was committed.
>
>The next change was to avoid emiting data into ioconf.c twice.
>
>I'd guess that that change caused it to also fail to emit some needed
>data, even once, but Christos will know, once he sees exactly what you
>are doing.   Don't alter your files in any way, send exactly what you
>are using that breaks (one of them, if there is more than one.)
>
>While, as Paul said, there have been changes, they weren't intended to
>invalidate any CONFIG files - the files.* files changed a little, that's
>why the grammar version bump, but kernel config files did not.
>Further while config is now stricter, it should generate errors if
>there's a problem, not bad ioconf.c files.

So the problem here now is that removing a parent device does not remove
all the children because the cfparents are not being shared anymore.
The code was changed so that cfparent structures are being separately
allocated separated if the "with attachment" argument is different,
but having their id's merged later. This prevents some of the children
to be deleted when you "no parent". This change was necessary to prevent
merging of locators in the condition that we had the the same
"child at parent" pair but with different attachments. It is not a big
deal, and can be fixed...

christos