Re: [m5-dev] Test Repository
My biggest worry about 3-6 months is that we often have fixes that are important and more recent than 3-6 months. Beta 5 is barely three months old and has at least two important patches, right? I was just going to use that same evidence to argue the opposite... the fact that beta5 is 3 months old and we're still finding significant bugs (including the assertion violation that Sujay posted about yesterday, which coincidentally Brad had just run into as well) says to me that we don't want to consider anything as stable until it's been through at least 3 months of availability. There are also in-tree branches that can be maintained which are essentially special uses of tags. Perhaps we should learn how those work, but I don't want to maintain a separate stable version. Seems like the big thing is that we want to separate bug fixes to the stable rev from new features/enhancements that haven't been widely tested. One solution is along the lines of what you suggested... maybe we maintain the bleeding edge version as a public mq patch list, and the stable version is just what's fully committed to the repo. Bug fix patches can then bypass new-feature patches to get into the stable version more quickly. One thing we'd have to emphasize internally is that pushing to the public patch list should still be done only when you have the same level of confidence that you currently should have before pushing to the central repo. Another concern I have is that I haven't used multiple mq patchsets much... if I have this public patchset because I'm on the bleeding edge, plus maybe some internal company shared patchset for the stuff I'm working on with colleagues, plus my own patches for what I'm currently working on, how cumbersome does that get? Maybe we should open this part of discussion to m5-users. Explain that we don't have tons of time to maintain old versions, and find out how many people would track the current revs. If we narrow it down to a couple of concrete options and can't decide among them, then asking m5-users sounds fine. I'd rather not move a very general discussion over there though. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
On Jun 7, 2008, at 2:09 PM, Steve Reinhardt wrote: My biggest worry about 3-6 months is that we often have fixes that are important and more recent than 3-6 months. Beta 5 is barely three months old and has at least two important patches, right? I was just going to use that same evidence to argue the opposite... the fact that beta5 is 3 months old and we're still finding significant bugs (including the assertion violation that Sujay posted about yesterday, which coincidentally Brad had just run into as well) says to me that we don't want to consider anything as stable until it's been through at least 3 months of availability. To jump in here, the thing is we're not finding these bugs. Saying there needs to be 3 months of testing before we release something marked stable only works if its likely that the people running the bleeding edge are will find and fix bugs before they end up in changes encompassed by the stable tag. Other users found all these cache bugs, we didn't. I personally use the most basic memory hierarchy, it takes someone coming around and deciding that they want to look at configure Z that no one has ever tried before that exposes the problem. If that only happens to revisions that are marked stable its not clear that waiting 3 months helps at all. There are also in-tree branches that can be maintained which are essentially special uses of tags. Perhaps we should learn how those work, but I don't want to maintain a separate stable version. Seems like the big thing is that we want to separate bug fixes to the stable rev from new features/enhancements that haven't been widely tested. One solution is along the lines of what you suggested... maybe we maintain the bleeding edge version as a public mq patch list, and the stable version is just what's fully committed to the repo. Bug fix patches can then bypass new-feature patches to get into the stable version more quickly. That's ok, but the issue here is that merging patches really is an ugly business. One thing we'd have to emphasize internally is that pushing to the public patch list should still be done only when you have the same level of confidence that you currently should have before pushing to the central repo. Another concern I have is that I haven't used multiple mq patchsets much... if I have this public patchset because I'm on the bleeding edge, plus maybe some internal company shared patchset for the stuff I'm working on with colleagues, plus my own patches for what I'm currently working on, how cumbersome does that get? It's not bad, patch sets can just be directories under .hg/patches. So you can have stable, internal, and mine. Maybe we should open this part of discussion to m5-users. Explain that we don't have tons of time to maintain old versions, and find out how many people would track the current revs. If we narrow it down to a couple of concrete options and can't decide among them, then asking m5-users sounds fine. I'd rather not move a very general discussion over there though. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
Sort of a multi-reply here... On Sat, Jun 7, 2008 at 11:36 AM, Ali Saidi [EMAIL PROTECTED] wrote: To jump in here, the thing is we're not finding these bugs. Saying there needs to be 3 months of testing before we release something marked stable only works if its likely that the people running the bleeding edge are will find and fix bugs before they end up in changes encompassed by the stable tag. Other users found all these cache bugs, we didn't. I personally use the most basic memory hierarchy, it takes someone coming around and deciding that they want to look at configure Z that no one has ever tried before that exposes the problem. If that only happens to revisions that are marked stable its not clear that waiting 3 months helps at all. That's a reasonable argument... it's not clear how many people would use bleeding edge vs. stable. Seems like the big thing is that we want to separate bug fixes to the stable rev from new features/enhancements that haven't been widely tested. One solution is along the lines of what you suggested... maybe we maintain the bleeding edge version as a public mq patch list, and the stable version is just what's fully committed to the repo. Bug fix patches can then bypass new-feature patches to get into the stable version more quickly. That's ok, but the issue here is that merging patches really is an ugly business. [...] It's not bad, patch sets can just be directories under .hg/patches. So you can have stable, internal, and mine. Aren't these statements contradictory? If you have the patch sets under separate subdirs, can they come from different repos? Would you still have to manually merge the series file? I don't totally blame Gabe for having the willies about this. On Sat, Jun 7, 2008 at 11:58 AM, Ali Saidi [EMAIL PROTECTED] wrote: The problem I have with as set of patches is that someone then has to go an get M5 and get this set of patches and apply them. It just raises the barrier to entry even more. If you're not using the bleeding edge version then you wouldn't need/want the patches, so I don't think it raises the barrier to novices. It would make transitioning to the bleeding edge a little more complicated, but nothing we can't overcome with a good FAQ. (Not to say I'm wedded to this idea... I still think your other objections are valid.) On Sat, Jun 7, 2008 at 12:26 PM, nathan binkert [EMAIL PROTECTED] wrote: So, do you want to maintain a separate branch of all of those fixes for several months? I don't. Me neither... that's why I brought up the idea of using a patch queue. Many of those bugs would also not be found if it weren't for people other than us, because as you say we don't do enough testing on our own since we don't use it in a wide enough range of circumstances. That's basically the same argument Ali made... I guess the key thing with Linux is that there are enough random people who use the release candidates to make them valid testing vehicles. My main fear is that if all we offer as a default download is the tip, then if something broken gets in there and someone downloads m5 for the first time and it doesn't work, that's not good. Maybe Nate's idea of automatically advancing the stable pointer once we've run the fullest possible set of regressions is the right way to go, and we can try harder to make sure that when we see some configuration break we create a regression test for it. That would go along with making the test framework a little more flexible, so we can have regressions that depend on files we can't export (like SPEC) that only run when appropriate, and maybe some staging mechanism that lets us run 1/N of the really long regressions every day instead of trying to do them all once every N days. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
Aren't these statements contradictory? If you have the patch sets
under separate subdirs, can they come from different repos? Would you
still have to manually merge the series file? I don't totally blame
Gabe for having the willies about this.
Yeah, it sorta gives me the willies too. Maybe what I suggest below
could be better.
My main fear is that if all we offer as a default download is the tip,
then if something broken gets in there and someone downloads m5 for
the first time and it doesn't work, that's not good. Maybe Nate's
idea of automatically advancing the stable pointer once we've run the
fullest possible set of regressions is the right way to go, and we can
try harder to make sure that when we see some configuration break we
create a regression test for it.
I think this, combined with something like a testing repository which
has regular regressions run as well and is maybe similar to the
mercurial crew repository. Basically, people are allowed to push more
speculative things to the testing repository, and they'll get
regressions run on that repository. (If we do some sort of automatic
bisect, that would be awesome) If the testing repository gets totally
whacked, it's easy to blow it away and just ask people to re-add
stuff. Maybe this should be done with a mq repository instead of a
normal repository. (Is this what you had in mind steve?) This way,
when people commit stuff, they can remove it from the queue and not
figure out how to merge it. We could also alternatively come up with
some way to just have a directory of mq trees that can be individually
maintained by people, and have the regression framework automatically
do a separate regression on all of the mq trees that are there.
That would go along with making the
test framework a little more flexible, so we can have regressions that
depend on files we can't export (like SPEC) that only run when
appropriate, and maybe some staging mechanism that lets us run 1/N of
the really long regressions every day instead of trying to do them
all once every N days.
I am willing to work on improving the testing framework to make adding
tests easier. I'd like to base it more on SConscript stuff than just
the existence of directories. That way you could do something like
Test('quick', mytestdir). The result would be that it would work
with extras where we could keep the spec regressions and private
regressions. I'd love it if someone volunteered to do the bisect part
though.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
On Jun 7, 2008, at 5:52 PM, Ali Saidi wrote: On Jun 7, 2008, at 5:44 PM, nathan binkert wrote: Aren't these statements contradictory? If you have the patch sets under separate subdirs, can they come from different repos? Would you still have to manually merge the series file? I don't totally blame Gabe for having the willies about this. Yeah, it sorta gives me the willies too. Maybe what I suggest below could be better. They aren't. Merging patches in an ugly business that I think we should avoid. MQ is pretty flexible about patches and subdirectoires so you can have various directories under .hg/patches each of which is a hg repository, however hg qcommit and the like won't work. Yes you would have to manually update the series file with all the patches from each directory. In reality if we went down this path --- which I'm not endorsing at all --- I would be tempted to hack MQ so that the root series file could just be pointers to other series files. My main fear is that if all we offer as a default download is the tip, then if something broken gets in there and someone downloads m5 for the first time and it doesn't work, that's not good. Maybe Nate's idea of automatically advancing the stable pointer once we've run the fullest possible set of regressions is the right way to go, and we can try harder to make sure that when we see some configuration break we create a regression test for it. I think this, combined with something like a testing repository which has regular regressions run as well and is maybe similar to the mercurial crew repository. Basically, people are allowed to push more speculative things to the testing repository, and they'll get regressions run on that repository. (If we do some sort of automatic bisect, that would be awesome) If the testing repository gets totally whacked, it's easy to blow it away and just ask people to re-add stuff. Maybe this should be done with a mq repository instead of a normal repository. (Is this what you had in mind steve?) This way, when people commit stuff, they can remove it from the queue and not figure out how to merge it. We could also alternatively come up with some way to just have a directory of mq trees that can be individually maintained by people, and have the regression framework automatically do a separate regression on all of the mq trees that are there. I just look a quick look at the hg webserver code. There isn't a direct way to download a revision. We could add one, or we could go back to my original suggestion that we have m5-stable and m5-dev and just pull to m5-stable at whatever interval. I even wrote a script to spam m5-dev if more than XXX days had gone by without an update to m5- stable. Just like Nate says we can then whack m5-dev if something goes awry and reclone from m5-stable. Another reason to have separate repos instead of just tagging if we're going to do stuff at this rate is that each retagging generates a new changeset. Pulling from a repo named x to a repo named y doesn't. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
What if it's supposed to be UM and MIPS? [(UM, [2006], ['Blah']), (MIPS, [2007], ['Foo'])] ?? Ali On Jun 1, 2008, at 4:34 PM, nathan binkert wrote: Looking through the mips directory for files that are just copyright MIPS and not UM interrupts.cc seems to be derived from alpha/interrupts.hh linux/linux.hh is exactly the same as alpha/linux/linux.hh with some constants changed linux/linux.cc is s/AlphaLinux/MipsLinux/g of alpha/linux/linux.cc mips_core_specific.cc is ev5.cc with most of the code commented out utility.cc has 25 lines verbatim from alpha/utility.cc regfile.cc is very similar to sparc/regfile.cc For those files, are you willing to give me code that has what the copyrights should be? It should look like this: (There are constants called UM and MIPS that you can use instead of the full institution name) 'src/dev/mips/MipsConsole.py' : [(UM, [2007], ['Korey Sewell'])], 'src/dev/sparc/T1000.py' : [(UM, [2006,2007], ['Gabe Black'])], Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
exactly. On Mon, Jun 2, 2008 at 7:26 AM, Ali Saidi [EMAIL PROTECTED] wrote: What if it's supposed to be UM and MIPS? [(UM, [2006], ['Blah']), (MIPS, [2007], ['Foo'])] ?? Ali On Jun 1, 2008, at 4:34 PM, nathan binkert wrote: Looking through the mips directory for files that are just copyright MIPS and not UM interrupts.cc seems to be derived from alpha/interrupts.hh linux/linux.hh is exactly the same as alpha/linux/linux.hh with some constants changed linux/linux.cc is s/AlphaLinux/MipsLinux/g of alpha/linux/linux.cc mips_core_specific.cc is ev5.cc with most of the code commented out utility.cc has 25 lines verbatim from alpha/utility.cc regfile.cc is very similar to sparc/regfile.cc For those files, are you willing to give me code that has what the copyrights should be? It should look like this: (There are constants called UM and MIPS that you can use instead of the full institution name) 'src/dev/mips/MipsConsole.py' : [(UM, [2007], ['Korey Sewell'])], 'src/dev/sparc/T1000.py' : [(UM, [2006,2007], ['Gabe Black'])], Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
I'm sending this again since apparently not everyone got it. nathan binkert wrote: A few (a vast minority) of .isa files for x86 should have UM copyright on them. There are a couple which are copied basically from Alpha/SPARC which should be fairly obvious since I think they have other people in the authors. There are a few which I did a little with while working over the semester which could also have UM added. Can you list them? I'm not going to go through them. Which? The x86 files that came from Alpha/SPARC, or the ones I worked on my last semester? For the former in arch/x86/isa see the list below. The rest of arch/x86 should have both except for the second list below. For the later, I sent an email earlier where I had a command that pulled that out of mercurial along with the list it generated. It had some junk tagging along but it was fairly short and would be easy to get the info from. // // From other ISAs // arch/x86/isa/formats/ basic.isa unimp.isa unknown.isa The below did not. The copyright was just copied over. I may have modified them in my last semester. error.isa multi.isa string.isa syscall.isa arch/x86/isa/ includes.isa macroop.isa main.isa operands.isa The below did not. The copyright was just copied over. I may have modified them in my last semester. macroop.isa microasm.isa specialize.isa Some files in arch/x86/isa/microops/ have UM copyrights but none of them were from another ISA. // // arch/x86/ not needing UM copyright // X86System.py X86TLB.py emulenv.[cc|hh] floatregs.hh everything in insts except for insts/static_inst.[cc|hh] intregs.hh miscregs.hh pagetable_walker.[cc|hh] predecoder.[cc|hh] predecoder_tables.cc segmentregs.hh smbios.[cc|hh] x86_traits.hh This is being somewhat liberal in what would be considered derived (aka I erred on the side of derived). Also, I see arch/x86/template.hh which I never intended to commit. I'm not sure how it snuck in there but you should feel free to nuke it. There's also a temporal issue where UM copyrights might not be applicable on changsets before a certain date, but to be technically correct should be applied afterwards. I don't get this. You mean when you were at HP full time? No, I'm talking about the ones I modified when I was back at UM for my last semester. Before I came back they were HP only. When I made my first change at UM, then they should be UM/HP. This is of course excluding the ones that started out as both HP and UM because I copied them from other ISAs. I think the cost of being super exact is more trouble than it's worth and over copyrighting stuff might be the way to go. Another thing I'm thinking is that a lot of those .isa files are fairly short, and having two copyrights on them could make them an order of magnitude (or more) longer than they would be otherwise. There's going to be a LOT of extra text there that might go better in a generic license file for all that code than in every single file. I'll leave that up to you guys. We have to put the license on every file. I agree that there are tons of files. Can you clean that up to reduce the number? I never really understood why you had so many. It's not that it's messy, it's categorizing the instructions like they are in the AMD manuals. They have a two level hierarchy for instruction categories which I mimic with directories and files. Sometimes there are only a few simple instructions in a category so the file is short. Also, if a directory would have only one file in it, I just use the file directly. The thing with X86 is that there are piles and piles and piles of instructions which each have something like 4 or 5 different versions not counting different processor modes, submodes, operand widths, address widths, stack widths, immediate widths, addressing modes, prefixes, blah blah blah blah blah. I compressed that substantially using mostly the same type of templating mechanism as in the real (in that patent) decoder, but it's still pretty enormous. They take the C in CISC very seriously. You do end up with a lot of small files that way, but I would argue that's a lot better than a 10,000 line long monster. I can squish some of the smaller one together into a single file separated by big chunky comments or something in the future to cut down on some of the girth. Also, not that I'm arguing, but why -do- we put the copyright on everything directly? Also, I haven't at any point in the entire time I've been working with M5 done anything with the copyrights, including the dates, other than change the authors line. The dates on files I did are worked on are probably totally nonsense. Aren't copyrights good for like a thousand years anyway? Can you fix them up after the repository is done? You should be updating dates on any files that you make major revisions to. We all should. Copyrights are generally between 50-100 years. I'll try to
Re: [m5-dev] Test Repository
No because it wouldn't be clear. I also don't want to go through the lawyers again. We're stuck with it the way it is. Nate On Mon, Jun 2, 2008 at 6:39 PM, Gabe Black [EMAIL PROTECTED] wrote: Just to shorten things up a bit, would it be possible to somehow just add the extra clause for HP if the other copyright is already on there? Something like non-commercial blah blah, and then the stuff above too. It looks like it's basically the same text just with the extra couple of paragraphs at the top. Gabe We have to put the license on every file. I agree that there are tons of files. Can you clean that up to reduce the number? I never really understood why you had so many. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
Looking through the mips directory for files that are just copyright MIPS and not UM interrupts.cc seems to be derived from alpha/interrupts.hh linux/linux.hh is exactly the same as alpha/linux/linux.hh with some constants changed linux/linux.cc is s/AlphaLinux/MipsLinux/g of alpha/linux/linux.cc mips_core_specific.cc is ev5.cc with most of the code commented out utility.cc has 25 lines verbatim from alpha/utility.cc regfile.cc is very similar to sparc/regfile.cc For those files, are you willing to give me code that has what the copyrights should be? It should look like this: (There are constants called UM and MIPS that you can use instead of the full institution name) 'src/dev/mips/MipsConsole.py' : [(UM, [2007], ['Korey Sewell'])], 'src/dev/sparc/T1000.py' : [(UM, [2006,2007], ['Gabe Black'])], Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
Korey Sewell wrote:
Is something coined as derived from a particular code because it
uses the same interface?
In some sense, any code you do within M5 has to be using that
interface in order for it to work.
Thus, isnt anything conforming to the whatever interface is defined derived?
My understanding is that things using the same interface are not
derived. If they use or are based on the same implementation, then I
think they're considered derived. For instance, the MIPS predecoder you
did at UM. I changed the interface for it when I added a predecoder, but
since I didn't change the implementation (that I remember) it would be
copyright UM and not HP. Maybe? It is a little confusing.
- i dont remember coding that getArgument() 25 lines. Gabe?
- MIPS (c) and I guess a UM (c) for that 25 line
If you do
hg annotate arch/mips/utility.cc
you get a bunch of stuff with
5247: getArgument(ThreadContext *tc, int number, bool fp)
5247: {
5247: #if FULL_SYSTEM
5247: if (number NumArgumentRegs) {
5247: if (fp)
5247: return tc-readFloatRegBits(ArgumentReg[number]);
5247: else
5247: return tc-readIntReg(ArgumentReg[number]);
5247: } else {
in it, and then if you do
hg log -r 5247
you get
changeset: 5247:7bacaaffcf59
parent: 5221:7814467db7f4
user:Korey Sewell [EMAIL PROTECTED]
date:Tue Nov 13 16:58:16 2007 -0500
summary: Add in files from merge-bare-iron, get them compiling in FS
and SE mode
Now, I think this was where things were sort of bolted together in a
less than ideal way, so I'm not sure who actually wrote that code. I did
modify it to make ArgumentReg look up in an array rather than do an
addition to a base, but other than that I don't think I'm responsible.
If I had to guess, I'd say it originally came from Alpha, or maybe
passed through SPARC on it's way from Alpha.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
Actually, I misspoke. The small files are the .py files in arch/x86/isa/insts/** which have a single variable declared holding microcode. The .isa files process them and do a few other things and tend to be longer. Gabe Gabe Black wrote: A few (a vast minority) of .isa files for x86 should have UM copyright on them. There are a couple which are copied basically from Alpha/SPARC which should be fairly obvious since I think they have other people in the authors. There are a few which I did a little with while working over the semester which could also have UM added. There's also a temporal issue where UM copyrights might not be applicable on changsets before a certain date, but to be technically correct should be applied afterwards. I think the cost of being super exact is more trouble than it's worth and over copyrighting stuff might be the way to go. Another thing I'm thinking is that a lot of those .isa files are fairly short, and having two copyrights on them could make them an order of magnitude (or more) longer than they would be otherwise. There's going to be a LOT of extra text there that might go better in a generic license file for all that code than in every single file. I'll leave that up to you guys. Also, I haven't at any point in the entire time I've been working with M5 done anything with the copyrights, including the dates, other than change the authors line. The dates on files I did are worked on are probably totally nonsense. Aren't copyrights good for like a thousand years anyway? Also, please ignore anything in here you guys have already addressed. Checking email is annoyingly slow so I'm reading these one at a time. Gabe nathan binkert wrote: Found a couple of bugs this morning. New version uploaded. We're getting to the point where everything is correct, and the main questions I have are: 1) Should the UM copyright even be on the x86 .isa files? Seems like the instruction definitions at least shouldn't have any UM. Gabe? 2) Should any of the MIPS files have the UM copyright on them? Ali, Korey? Can you look at those? 3) Are there any files that should be removed from the repo? right now, I've removed: 'util/setup-web99', 'util/setup-spec', 'util/setup-specweb', 'util/greprevs', 'util/chgcopyright') 4) Are there any other copyrights or dates that should be fixed? 5) Anything else need to be done? Nate On Sat, May 31, 2008 at 10:53 PM, nathan binkert [EMAIL PROTECTED] wrote: I've uploaded a new version with fixes for Ali and a few other things. I know of no bugs in this revision. Please find some. Nate On Sat, May 31, 2008 at 10:14 PM, Steve Reinhardt [EMAIL PROTECTED] wrote: I don't know if they should be updated or not... I didn't mean to imply that they should be, just that if you were updating them you weren't getting it right. Steve On Sat, May 31, 2008 at 10:04 PM, nathan binkert [EMAIL PROTECTED] wrote: The dates weren't computed. They were taken from the original files. I only updated the copyright text, not the dates. I could compute them, but it seems that little tiny changes shouldn't cause a copyright change and it would be somewhat challenging to figure out which changes were big and which were small. Do you think they should be computed? I think that particular SConscript copyright for example was just copied by me when I started working on that code, and it just took a long ass time for me to commit it. Nate How are the copyright dates being computed? I'm looking through src/mem/cache, and they don't seem right at all... most of them have dates that end in 2005, and the SConscript has a date of 2006 even though hg shows that it was created in 2007 and modified in 2008. Steve On Fri, May 30, 2008 at 10:39 PM, nathan binkert [EMAIL PROTECTED] wrote: Alright, after a bunch of tinkering, I think I've got a working repository ready for export. It can be found at m5sim.org:/repo/new Please, please test things out. Look at copyrights, check out old revisions, look at more copyrights, please make sure I didn't mess anything up. I really need the help here. I don't want to release the repo and find out that I've screwed it all up. I haven't done any test compiles in a while, so that sort of thing would help too. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org
Re: [m5-dev] Test Repository
A few (a vast minority) of .isa files for x86 should have UM copyright on them. There are a couple which are copied basically from Alpha/SPARC which should be fairly obvious since I think they have other people in the authors. There are a few which I did a little with while working over the semester which could also have UM added. Can you list them? I'm not going to go through them. There's also a temporal issue where UM copyrights might not be applicable on changsets before a certain date, but to be technically correct should be applied afterwards. I don't get this. You mean when you were at HP full time? I think the cost of being super exact is more trouble than it's worth and over copyrighting stuff might be the way to go. Another thing I'm thinking is that a lot of those .isa files are fairly short, and having two copyrights on them could make them an order of magnitude (or more) longer than they would be otherwise. There's going to be a LOT of extra text there that might go better in a generic license file for all that code than in every single file. I'll leave that up to you guys. We have to put the license on every file. I agree that there are tons of files. Can you clean that up to reduce the number? I never really understood why you had so many. Also, I haven't at any point in the entire time I've been working with M5 done anything with the copyrights, including the dates, other than change the authors line. The dates on files I did are worked on are probably totally nonsense. Aren't copyrights good for like a thousand years anyway? Can you fix them up after the repository is done? You should be updating dates on any files that you make major revisions to. We all should. Copyrights are generally between 50-100 years. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
are all the patches supposed to be committed now in some order or do you want everything working as is? You should be doing all of your work in mercurial queues. All you'll need to do is get everything into a patch, copy .hg/patches to the new repo's .hg directory, and delete .hg/patches/status. You can then start doing your queue commands again. what's the process for editing code later? I'm assuming stable tree and developmental tree? Rules for checking in/out of both? There should be just one m5 tree. People can feel free to have their own development trees, and we can create something akin to the mercurial crew if we like. In general, you shouldn't be committing stuff to the main tree that isn't tested anyway. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
I'm going to look at this now. Should I use the original one or is there an updated version? Gabe nathan binkert wrote: I've done my testing and I'm mostly happy. I checked that the tags were regenerated properly and that b4, b5, and tip all compile. Looking through a diff of the old and new repository and didn't find anything wrong and I also then greped the diff to remove the license text and didn't find much of anything wrong with that either. I found one bug. On python files that have a #! line, if I added a new copyright (because none existed), the copyright was added before the #! line and not after. I think I've fixed this. One little thing that I noticed is that in the license there is a space after the * or # between the two main paragraphs sometimes between the paragraphs and the authors and sometimes between the first line and the main paragraphs. Ok, I'll try to see if I understand why. Can you give me a concrete example of where this happens? Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
BTW, I'm back on satellite internet again so don't expect this to be lightning quick. Gabe Nathan Binkert wrote: I keep updating the original location On May 31, 2008, at 3:20 PM, Gabe Black [EMAIL PROTECTED] wrote: I'm going to look at this now. Should I use the original one or is there an updated version? Gabe nathan binkert wrote: I've done my testing and I'm mostly happy. I checked that the tags were regenerated properly and that b4, b5, and tip all compile. Looking through a diff of the old and new repository and didn't find anything wrong and I also then greped the diff to remove the license text and didn't find much of anything wrong with that either. I found one bug. On python files that have a #! line, if I added a new copyright (because none existed), the copyright was added before the #! line and not after. I think I've fixed this. One little thing that I noticed is that in the license there is a space after the * or # between the two main paragraphs sometimes between the paragraphs and the authors and sometimes between the first line and the main paragraphs. Ok, I'll try to see if I understand why. Can you give me a concrete example of where this happens? Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
For those files in the x86 dir, we must put the HP non commercial license. The UM license is standard BSD, so for those files, we have both. On Sat, May 31, 2008 at 11:28 PM, Gabe Black [EMAIL PROTECTED] wrote: There are two copyrights on src/arch/x86/process.cc. Didn't we say we were putting multiple names on the same copyright? Gabe Gabe Black wrote: BTW, I'm back on satellite internet again so don't expect this to be lightning quick. Gabe Nathan Binkert wrote: I keep updating the original location On May 31, 2008, at 3:20 PM, Gabe Black [EMAIL PROTECTED] wrote: I'm going to look at this now. Should I use the original one or is there an updated version? Gabe nathan binkert wrote: I've done my testing and I'm mostly happy. I checked that the tags were regenerated properly and that b4, b5, and tip all compile. Looking through a diff of the old and new repository and didn't find anything wrong and I also then greped the diff to remove the license text and didn't find much of anything wrong with that either. I found one bug. On python files that have a #! line, if I added a new copyright (because none existed), the copyright was added before the #! line and not after. I think I've fixed this. One little thing that I noticed is that in the license there is a space after the * or # between the two main paragraphs sometimes between the paragraphs and the authors and sometimes between the first line and the main paragraphs. Ok, I'll try to see if I understand why. Can you give me a concrete example of where this happens? Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Test Repository
The dates weren't computed. They were taken from the original files. I only updated the copyright text, not the dates. I could compute them, but it seems that little tiny changes shouldn't cause a copyright change and it would be somewhat challenging to figure out which changes were big and which were small. Do you think they should be computed? I think that particular SConscript copyright for example was just copied by me when I started working on that code, and it just took a long ass time for me to commit it. Nate How are the copyright dates being computed? I'm looking through src/mem/cache, and they don't seem right at all... most of them have dates that end in 2005, and the SConscript has a date of 2006 even though hg shows that it was created in 2007 and modified in 2008. Steve On Fri, May 30, 2008 at 10:39 PM, nathan binkert [EMAIL PROTECTED] wrote: Alright, after a bunch of tinkering, I think I've got a working repository ready for export. It can be found at m5sim.org:/repo/new Please, please test things out. Look at copyrights, check out old revisions, look at more copyrights, please make sure I didn't mess anything up. I really need the help here. I don't want to release the repo and find out that I've screwed it all up. I haven't done any test compiles in a while, so that sort of thing would help too. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
