yep
On Thu, Mar 21, 2013 at 12:08 PM, Steve Reinhardt <[email protected]> wrote: > In general it would be nice to have some guidelines like this, but if in > the immediate case we don't really need a namespace at all, I'm quite happy > with that solution. > > Steve > > > On Thu, Mar 21, 2013 at 11:03 AM, nathan binkert <[email protected]> wrote: > >> We could have an Amba Namespace and a Device class, so it'd be >> Amba::Device. >> >> We might also consider a different naming convention for namespaces. >> >> Amba_Device, amba_device, amba_ns, AmbaNS, NSAmba, AmbaNamespace, >> AmbaStuff, AmbaIsThisNamespaceStuffUseful, >> AmbaShouldWeUseMoreNamespaces? >> >> Nate >> >> On Thu, Mar 21, 2013 at 9:34 AM, Steve Reinhardt <[email protected]> wrote: >> > Don't ask me why, but somehow I'm in a mood to actually fix stupid little >> > things that annoy me instead of just letting them slide. (See the >> swig_env >> > debate.) Another one of those things I recently ran across is that most >> of >> > our I/O device classes end in 'Device', but a couple of them (PciDe and >> > IntDev) end in just 'Dev'. Nothing a quick perl pie can't fix, right? >> > >> > Turns out that there's a complication in that there's an AmbaDev >> namespace >> > as well as an AmbaDevice class in src/dev/arm/amba_device.hh, so my nice >> > perl substitution renamed the namespace to conflict with the class, and >> as >> > usual nothing is as easy as I thought it would be. >> > >> > Even disregarding the perhaps minimal value of my initial purpose, I'll >> > posit that it's not good to have a namespace and a class whose names >> differ >> > only in that one is an abbreviated form of the other. So I'd like to >> take >> > care of this, but rather than just post a patch and see what happens, I >> > thought I'd see if anyone cared how. Basically I see two options: >> > >> > 1. Get rid of the namespace and make the contents (a few const ints and a >> > function) public static members of the AmbaDevice class. I tried this >> and >> > it works fine, with one side complication of the DPRINTF name() thing not >> > dealing well with being in a static method, but I can handle that. >> > >> > 2. Rename the namespace to something a little more descriptive. >> > >> > Anyone care? Since I already did #1, that's what I'll stick with unless >> I >> > hear otherwise. If you prefer #2, please provide a suggested new name as >> > well. >> > >> > Thanks, >> > >> > Steve >> > _______________________________________________ >> > gem5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/gem5-dev >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
