Page MenuHomeFreeBSD

mixer: change `dunit` to `default_unit`
AbandonedPublic

Authored by christos on Oct 1 2021, 10:06 AM.
Referenced Files
Unknown Object (File)
Jan 11 2024, 10:20 PM
Unknown Object (File)
Nov 15 2023, 10:57 PM
Unknown Object (File)
Nov 14 2023, 12:08 PM
Unknown Object (File)
Nov 1 2023, 9:19 PM
Unknown Object (File)
Oct 13 2023, 11:13 AM
Unknown Object (File)
Oct 9 2023, 10:00 PM
Unknown Object (File)
Sep 14 2023, 9:05 PM
Unknown Object (File)
Jul 28 2023, 7:07 PM
Subscribers
None

Details

Reviewers
hselasky
Summary

default_unit is a clearer name.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

christos created this revision.

Change Makefile and Symbol.map names as well.

Can you also update the Symbol versioning file with the new symbol, while not removing the old one!

MLINKS+= needs an update too.

In the C-code you need to add:

symver(mixer_get_default_unit, mixer_get_dunit, FBSD_1.7);
symver(mixer_set_default_unit, mixer_set_dunit, FBSD_1.7);

From now on, such changes must be backwards compatible.

lib/libmixer/Symbol.map
18

mixer_get/set_dunit must remain. You can only add stuff.

Can you also update the Symbol versioning file with the new symbol, while not removing the old one!

MLINKS+= needs an update too.

In the C-code you need to add:

symver(mixer_get_default_unit, mixer_get_dunit, FBSD_1.7);
symver(mixer_set_default_unit, mixer_set_dunit, FBSD_1.7);

From now on, such changes must be backwards compatible.

Since the library is so new, do we need to do this and not just rename the
symbols to keep it clean, at least this time?

Since the library is so new, do we need to do this and not just rename the
symbols to keep it clean, at least this time?

I see this more of an exercise for you.

The problem is that 3rd parties may already be using this stuff, even though it has just existed for a week, and I don't want to continue breaking stuff :-)

This is what makes FreeBSD great sometimes.

--HPS

Since the library is so new, do we need to do this and not just rename the
symbols to keep it clean, at least this time?

I see this more of an exercise for you.

The problem is that 3rd parties may already be using this stuff, even though it has just existed for a week, and I don't want to continue breaking stuff :-)

This is what makes FreeBSD great sometimes.

--HPS

Fair enough.

I think "dunit" is just as good as "default_unit".

BTW: It is possible to make one differential revision depend on another.

I see now, this one was supposed to go first, then the other one which broke buildworld.

I think "dunit" is just as good as "default_unit".

If it is, we can keep it as is then, I don't mind personally.

BTW: It is possible to make one differential revision depend on another.

I see now, this one was supposed to go first, then the other one which broke buildworld.

Yeap, exactly.

BTW: If you first expand dunit -> default_unit, there are many other function names you should treat the same:

nmixers->num_mixers ?
recsrc -> recording_source

????

Also, people should read the manual page. Then the function name is not that important.

BTW: If you first expand dunit -> default_unit, there are many other function names you should treat the same:

nmixers->num_mixers ?
recsrc -> recording_source

????

True, let's keep it as is then, should I close the revision?

Yes, you can abandon this one if you like.