intr/x86: remove intr_bind() from x86

[ehem_freebsd_m5p.com]

Summary

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
remove.

[ehem_freebsd_m5p.com]

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.

[mjg]

maybe it is high time to add cpu_t

[ehem_freebsd_m5p.com]

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.

[mjg]

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.

[ehem_freebsd_m5p.com]

@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.

[mjg]

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.

[ehem_freebsd_m5p.com]

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)

[mjg]

ok then

[emaste]

sys/x86/x86/nexus.c

618–623

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