I'm just surprised how quickly they killed it off in the Linux kernel, considering the last Itanium processors where delivered in 2020. Other older, less used ISAs seem to have not had that level of treatment.

[illumos-gate] 16440 loader: comconsole reset the terminal and drain input on port setup -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16438 NFS4 xdr_share_access() fails to handle XDR_ENCODE path -- Toomas Soome <tsoome⊙mc>

I'm playing around with some modifications to the emlxs driver, I do not want to rebuild the whole illumos-gate. However the source tree has no dedicated makefile for that driver, instead the Makefiles are in usr/src/uts/common - is there some kind of voodoo make that I haven't found googling?

no, you've just discovered one of the least intuituve bits of how the kernel is made unfortunately... what you need to do is cd usr/src/uts/intel/emlxs and run dmake -e install from there

jbk: ah, thank you very much :)

you'll find dirs for most drivers in there, that's where you have to build them

I guess if I just want to *build* the driver, I just run dmake without -e install, right?

i believe -e is always used when building (you should still run bldenv xxxx.sh first to setup all the needed env vars)

jepp, I'm inside bldenv

i think we've found most of them, but sometimes if a particular makefile is goofy, dmake -e may not do anything (if it doesn't then try install)

install just puts it in the proto area ($ROOT)

it won't overwrite your running system

ah!

good :)

ah, it needs a full build initially as it seems. It tries to access genunix. ok, full build then

you can build in genunix first;)

and risk to miss out something else, I know what "dependency hell" means :)))

:D well, if you did make setup first in usr/src, you should be ok, but of course it is better to get full build first, less surprises this way

yeah, it's usually easier to start with a full build, then do your changes and incrementally build

Agnar: there are some scripts in usr/src/tools/quick which you can use as a model for a partial-tree build during development

but really you have to know what the prerequisites are.

and that's not something that Makefiles are good at expressing in a large tree.

I think the simplest thing is what we document in the developer's guide. Do a single full nightly, then go into the target directory and run dmake install.

I should dust off my old wxmakexref/wxbuild - it read the .make.state files from a nightly and could tell you which directories to build to generate the modified targets from a set of changed source files.

There's still the problem that Agnar has which is that the build directories are remote from the sources in many cases. (wxbuild predates the teamware -> hg migration and I had stopped using it by then because my mental map of the source tree was good enough)

The docs aren't perfect or the most discoverable, but if you're getting started I'd check out the baskc workflow building docs Agnar.

I'm glad I'm not the only one who's parsed .make.state for reasons

[illumos-gate] 16450 March 2024 hwdata update -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16451 bofi(4D) has weird and meaningless file permissions -- Richard Lowe <richlowe⊙rn>

[illumos-gate] 16457 loader: replace divide condition in biosdisk -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16404 amdzen should not allow DF reads with an unknown version -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16407 Raphael DF revision detection is incorrect -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16408 AMD Zen 5 CPC support -- Robert Mustacchi <rm⊙fo>