Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]

Hi,

On Wed, Nov 9, 2011 at 12:39 PM, Julian Elischer <julian_at_freebsd.org> wrote:
> On 11/8/11 9:29 PM, Arnaud Lacombe wrote:
> [...]
>
>> However, if you want to know, my heart tends to be with BSDs.
>> Unfortunately, it's a sad love-story where your Beloved keeps
>> deceiving you day after day. You want to change small bits at a time,
>> make several iteration of progress to make things brighter, but your
>> Beloved refuses any change because of too much inertia. Sad.
>
> mostly it's because you keep attacking your loved one with a steak knife.
> flowers might get you further.
Well, it would would seem that keeping sending patch is what you
consider "attacking your loved one with a steak knife", because yes,
this is what I will keep doing.

>>>
>>> so you are used to doing it that way.. but don't expect us to change just
>>> because that's what Linux does.
>>>
>> again, mentioning Linux is totally irrelevant. Use of Instruction
>> Pointer are implementation details for a not so intrusive solution to
>> the problem I pointed out, and which you are totally missing.
>
> since these modules were written many new options have come.
Maybe this is the real problem, FreeBSD is unable to keep up and to
make interfaces written +10 years ago evolves. Worst, you (committers)
keep on taking decision based on changes made 10 to 12 years ago that
are totally irrelevant today, making these decisions nothing but plain
bad.

>> well, you're lucky FreeBSD supports your device! Lately, we got lately
>> a shiny multi-queue network cards with bypass mechanism... that is not
>> supported in FreeBSD. So currently, we got an expensive paper-weight.
>
> well write a driver for it..
>
my time is limited, and you (FreeBSD folks) seem to love making it
even busier by your inability to make some parts of the system evolve,
or by taking bad decision. This generally happens when I try to
optimize some of our internal code path, hit a system bottleneck, try
to prove the system is wrong, and then eventually, think about
optimizing it, implement the solution one or twice, and get slammed
hard when I go public with both the proof of performance
hit/non-correctness/incompleteness and the correction. Unfortunately,
the time complexity of the whole process is 2^O(n) :(

> what do you think I'm doing with the driver I'm
> talking about?
> I wrote several bypass network card drivers when I was at cisco/ironport..
> it's not rocket science,
> though it would be nice if we were to come up with a standard interface for
> bypass interfaces.
indeed.

> That is a different topic though..
>
indeed.

>>> 1/ half the time freebsd will just immediatly assert on something and
>>> present you with the bug.. done.
>>>
>> well, certainly not from a release build; assertion are disabled.
>
> During development. we NEVER have bugs in production ;-)
>
[sic.]

>> [0]: I am able to crash any kernel between 7-STABLE to 9.STABLE within
>> minutes, with the right pattern and (mainstream and well supported)
>> hardware.
>
> and who have you reported that to?  bug number?
>
http://lists.freebsd.org/pipermail/freebsd-net/2011-September/029722.html

I suspect PR/155597 and a few other are related.

>> [3]: FreeBSD (8-STABLE) is way to limited and un-integrated to be
>> anywhere but useful, not to speak about kernel bug which leave the
>> system so fracked up that you have no other choice but to hard-reboot.
>
> bug number?
>
usb/156725, amd64/156726

 - Arnaud