On 07.11.2012 01:20, Attilio Rao wrote:
On Tue, Nov 6, 2012 at 11:17 PM, Ben Kaduk <minimar...@gmail.com> wrote:
I do not wish to belabor the point; we all have better things to do
with our time. Hopefully this is my last message on the topic.
On Tue, Nov 6, 2012 at 6:10 PM, Attilio Rao <atti...@freebsd.org> wrote:
The point is that KPI/KBI of -CURRENT can change as long as
__FreeBSD_version is bumped (and if you really want to know my
opinion, I already see this as a forceful thing because it would not
be necessary in my mind, but I second the will of the majority of
developers). So, if the KPI/KBI changes all the thirdy part code,
ports and everything else must adapt.
Yes, everything must adapt to changes in -current. I am arguing that,
if it is easy to do so, we should make the user experience for
*ordinary users* running -current as nice as possible. If we do not
have ordinary users running current, then our code does not get
real-world testing until RC builds, or even the .0 release. I think
it is well-accepted that we want to have the code in -current get
real-world testing; making the user experience nicer helps this to
happen. To me, it seems that the user experience is nicer if the KPI
change is delayed from the KBI change. We have mechanisms in place
that can enforce __FreeBSD_Version of kernel modules must match the
version of the running kernel, so I do not see how this procedure
would lead to silent binary incompatibility.
The courtesy you are mentioning here is the __FreeBSD_Version. Having
stricter rule would just meaning doing under-performing and unclean
job.
MPSAFE flag is not any longer supported and code needs to be ported
appropriately to -CURRENT interface.
That is the present state of affairs, yes. I am asking only, "think
of the users; can we make things easier for them?".
Maybe not in this case, but as something to keep in mind for the future.
I can understand your concern, but people using -CURRENT must be well
aware of the fact that this is a development branch and they cannot
expect too many safety belt mechanisms to be in place.
I think that the current model (break KBI/KPI at will, give
ports/thirdy part a way to recognize it via __FreeBSD_Version and move
on) is optimal because it doesn't limit the developer neither leaves
the user completely without a landmark on how to fix the problem.
It is all balancing in finding compromises :)
I would like to support Ben's position. We may not expect that all the
world is tracking our development in real time and adapt to our changes
at the same exact moment. As I understand, before this one change MPSAFE
flag was mandatory to have. After that one change MPSAFE is missing and
so must to be removed. Yes, in perspective that part of code in external
sources will be wrapped with respective ifdef's, but could we give world
some time window to adapt, leaving constant doing nothing in tree? What
is the price of having single define, comparing to headache even for one
user who was brave enough to run HEAD?
--
Alexander Motin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
