Page MenuHomeFreeBSD

intr/x86: remove intr_bind() from x86

Authored by on Oct 7 2022, 4:10 AM.
Referenced Files
Unknown Object (File)
Tue, Apr 16, 11:15 PM
Unknown Object (File)
Mar 23 2024, 1:37 PM
Unknown Object (File)
Mar 15 2024, 1:10 AM
Unknown Object (File)
Mar 11 2024, 7:52 AM
Unknown Object (File)
Mar 7 2024, 3:28 AM
Unknown Object (File)
Mar 1 2024, 4:32 AM
Unknown Object (File)
Feb 18 2024, 6:04 AM
Unknown Object (File)
Jan 28 2024, 5:19 PM



intr_bind(u_int vector, u_char cpu); looked suspicious since
everywhere "cpu" is a u_int and >256 processors isn't unreasonable now.
Upon checking, intr_bind() is not used anywhere in FreeBSD. Time to

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

Checking turned up a single use of intr_bind(), everywhere else intr_event_bind() was used. At this point the u_char is hazardous, so time to nuke the almost unused function.

maybe it is high time to add cpu_t

Having a cpu_t seems a bit overkill. Nearly everywhere uses u_int which works fine. Just in this instance I spotted something rather out of date. On the other hand if I was asked to review a diff which created a cpu_t, I would accept it if it looked reasonable.

But u_int is too wide and consequently wastes space, realistically short will be more than enough for a long time.

Sample user which would get past a certain threshold with an int instead of a short is struct vnode.

The current type mess needs to be cleaned up at some point and it's not going to be int.

@mjg aren't you discussing a distinct potential commit here? I don't believe that is how this is supposed to work.

If you're planning to introduce a differential to create a typedef cpu_t, then ask to keep intr_bind() and simply rebase this on top, I would be up for that. As stated I certainly wouldn't be against a cpu_t, just I don't feel it is urgent.

I presume there may be other changes in the pipeline which also happen to remove u_char or replace it with an int, in which case it would be duplicate work -- would have to be repeated after cpu_t shows up, so how about doing it first and saving on the churn.

Nope. This is purely a one-off which happened to show up in front of me when I was looking at something else. I kind of wonder whether intr_bind() should be fixed and turn into an inline static to start encouraging its use. Right now that single use in nexus was the only use and intr_event_bind() is used all over.

The real work I'm aiming for is closer towards D35559/D32504/D36610/D36628. (which seems a rather larger level of chaos)

This revision is now accepted and ready to land.Oct 15 2022, 10:12 AM
emaste added inline comments.

IMO we ought to make this change first, then can remove intr_bind in a second commit as it is then truly unused

This revision was automatically updated to reflect the committed changes.