On Tue July 1 2008 15:45:57 John Kasunich wrote:
> Sebastian Kuzminsky wrote:
>
> >> Now the problem:
> >>> This means TRUNK wont work on Dapper unless the
> >>> developer installs libpciaccess by hand. Hardy is here and it's
> >>> time to move on.
> >>
> >> I'm not ready to move on yet ;-)
> >
> > Sounds like emc2 2.2 is for you! :-P
>
> I want new features that will be part of EMC 2.3.x and beyond. I don't
> see why I should have to update my entire operating system to get them.
>
> Sure, someday there will be some killer feature (or killer bug) that
> forces us to drop support for Dapper in TRUNK. But this doesn't
> qualify, IMO.
I see your point.
There's a judgement call here: accumulating cruft to support older
platforms, or abandoning older platforms for a cleaner product.
Me, I'm allergic to cruft and I dont mind upgrading to stay in sync with
the rest of the open source community.
And IMO, upci+libpci definately counts as cruft.
I guess the board will decide? How does the emc2 project make decisions
like this?
> > I'd expect emc2 2.2 to be supported on Dapper et al in bugfix mode for
> > a long time to come, while development moves ahead in other branches,
> > on newer versions of the operating system, dropping support for older
> > distros as they age to unmaintainability.
>
> I intend to have both an installed 2.2 and one or more CVS checkouts on
> my machine. I admit that a regular user won't need or want to do that,
> but any developer might. If all I'm doing is running parts, I'll
> probably use the installed version. If I'm doing development, or
> testing something new that someone else has developed, or simply running
> a part that _needs_ a new feature, I'll use the newer version RIP. And
> eventually I'll replace 2.2.x with 2.3.x.
>
> For example, this week I need to test low-ppr threading. I've written
> the basic code on my development box, but I want to actually cut threads
> to make sure it works. You'd force me to install Hardy (or manually
> download and install libpciaccess) before I can run CVS code on my machine.
Or disable bfload and everything that depends on it. After someone adds
"configure --disable-bfload"...
> >> I realize that there will come a time when we have to move on from
> >> Dapper, just as we have moved on from 2.4 kernels, etc. But I don't
> >> think we've reached that point yet. TRUNK currently builds not only on
> >> Dapper, but on Breezy and on the BDI-4.51. I haven't discussed this
> >> specific issue with the board, but I think we had a general consensus
> >> that the 2.3.x release series wouldn't have Breezy and BDI support as
> >> "must have". But nobody has talked about dropping support for Dapper.
> >> I consider Dapper to be the mainstream, with Hardy as something for the
> >> early adopters to use.
> >
> > Ok, this is a good conversation to have.
> >
> > What distros are going to be supported by 2.3?
>
> I'd like to see:
>
> 1) Official support (including .debs) for Hardy with our RT kernel
>
> 2) Official support (including .debs) for Dapper with our RT kernel
>
> 3) Official support (.debs optional) for simulator mode on vanilla Hardy
> with the stock kernel
>
> 4) Official support (.debs optional) for simulator mode on vanilla
> Dapper with the stock kernal
>
> 5) Unofficial support (no .debs, but the code works if you compile it)
> for Breezy with our RT kernel
>
> 6) Unofficial support (no .debs, but the code works if you compile it)
> for BDI-4.51 (includes an RT kernel)
>
> 7) Unofficial support for simulator mode on "generic Linux", with the
> understanding that ./configure is going to fail until people install
> missing dependencies.
>
> I agree that is a conversation we should be having.
I dont want to support older distros. They hold us back.
Dapper doesnt have firefox 3, or even firefox 2. It's stuck back on gcc
4.0.3, glibc 2.3.6, gnome 2.12, KDE 3.5.2, and python 2.4. It's still
supported, but development has moved on.
"The 'portability to every insane system' disease causes insanity
on *all* platforms." -- H. Peter Anvin
> >>> I plan to support the 2.2 branch by using both upci and libpci
> >>> in bfload. I wont mess with upci, pci_read, or pci_write in 2.2.
> >>> libpci is available for Ubuntu releases back to Dapper [4].
> >>
> >> If it is possible to do this for 2.2, then why not do the same in trunk?
> >
> > Because it has bad smell. Two different PCI access libraries with
> > overlapping yet incompatible functionality (bus enumeration, device
> > representation etc). It's kind of a hokey setup...
>
> Understood. But hokey or not, it still needs to be done for 2.2. Once
> it is done and works, why not just keep using it?
Because then we'd keep smelling bad even on new distros!
> I thought we had talked about extending upci to provide config space
> access. I realize that might also be hokey, but it avoids a lot of the
> duplication duplication.
We did talk about that, and I dont think it'd be hokey to do that.
But in parallel with our conversation, I talked with the libpci folks.
Martin Mares said he'd gladly accept a patch to add BAR access to libpci.
Surely you agree it's best to put the development effort where it will
see the most use/debugging and help the greatest number of people.
Between either merging the libpci code into upci or merging the upci
code into libpci, the choice seems obvious to me.
But then someone on the linux-pci list suggested libpciaccess from X.org,
which already has everything we need. And that seemed an even better
choice to me.
Hm, how about this? We could switch bfload to libpciaccess, and fork
libpciaccess into our repo, for use on old platforms that dont have it
available "natively". We already carry a pci access library around with
us, might as well make it one that's seen some use and testing by the
community, something that might just be familiar to outsiders peeking in.
> > I'd rather move to a single pci library, and it helps that it's
> > relatively widely used, and maintained by someone else. It's just
> > cleaner.
>
> I guess "widely used" depends on your perspective. I have no data to
> back this up, but I think of our user base as being 10% pre-Dapper, 80%
> Dapper, and 10% Hardy. I'm sure the Hardy percentage will climb rapidly
> over the next year, but even in 2009 I bet Hardy will be less than 50%.
I meant the pci access library is widely used. X (and libpciaccess)
must have 1000,000x as many users as emc2 (and upci).
--
Sebastian Kuzminsky
my brothers are protons / my sisters are neurons
I stir it twice, it's instant family! -- Gogol Bordello
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
