Date: Sun, 13 Nov 2011 19:38:37 -0500 From: Arnaud Lacombe <lacombar@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-current@freebsd.org Subject: 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]] Message-ID: <CACqU3MXs39CY%2BUhgnm9DBxmYbsyh7oPJkba%2BbhCnS0TUodyoXw@mail.gmail.com> In-Reply-To: <4EBABAC1.2090003@freebsd.org> References: <CACqU3MU_Bk%2BcObCiUa2XtM7fLkSpSDzOZqoZ=khNOR-_6ptYYQ@mail.gmail.com> <4EB9C469.9070208@freebsd.org> <CACqU3MWkcKZ2cjh_VJueWUpOS7dzhu%2BMh8yYWVA8X9B9ykOW7w@mail.gmail.com> <4EB9E6FE.3060102@freebsd.org> <CACqU3MUjxFOBGF4zib=Wz6Vrt=Jrsur03g_U4-g4hg0iEnpVSA@mail.gmail.com> <4EBABAC1.2090003@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, Nov 9, 2011 at 12:39 PM, Julian Elischer <julian@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 ju= st >>> 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 f= or > 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? =A0bug 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MXs39CY%2BUhgnm9DBxmYbsyh7oPJkba%2BbhCnS0TUodyoXw>