IRC channel logs
2020-09-27.log
back to list of logs
<youpi>I don't think Richard cares about gender at all, he cares about technical soundness <AlmuHS>really, the gender might not be important <AlmuHS>the context is a message in which Richard attacked me and a other developers, putting us as "bad examples" <AlmuHS>I don't know the reason because him attack me and other newcomers. This phrase is a good example of this "(...) despite being a clueless inexperienced student". I was a student, but I'm not idiot <youpi>which is not actually an insult <youpi>it's only normal for students to be clueless <youpi>what he's concerned with is yound people not taking care of thinking that paying attention to details and overall design does matter <jrtc27>yeah I wouldn't trust 99% of the undergrads here with kernel code <jrtc27>you have got stuck in and learnt a lot from the process <jrtc27>the issue is that it's inevitable that the initial code will be poor quality and interacting with the maintainers will use up a lot of their time <jrtc27>and he is personally unwilling to put that effort in <youpi>yes, and and richard's concern is about the amount of time to be spend <AlmuHS>my first code was written fast, It was a simple draft <youpi>when progress can be noticed, a maintainer can be willing to take time <jrtc27>yes, which is fine for a uni project <youpi>but if the progress is slow, it's way harder to get motivated to spend it <youpi>yes, teachers are paid for that <AlmuHS>I was agree about I had to refactor It <jrtc27>heck I was pretty clueless when I first started with the hurd <jrtc27>took me months to understand how things worked <AlmuHS>I agreed with his ideas about refactor, applying OOP, splitting arch and non-arch dependant code... <AlmuHS>but I disagree with his attitude <jrtc27>personally I don't think the issue is whether people are clueless or not, the most important thing is how willing and able they are to learn <jrtc27>but not everyone has time to put into helping such people <AlmuHS>His ideas about refactor the code was fine, and I'm taking them in my current code. But I don't like his attitude <jrtc27>I don't know the context, but he claims you dismissed him so if that were true then I think it's fair for him to have held a low opinion of you <jrtc27>without digging through exactly what happened between you two I don't see a huge problem with what richard wrote <AlmuHS>the context was the Google Summer of Code. I asked a mentor, and he offered me for this <jrtc27>could maybe be expressed a bit less bluntly, but it seems reasonable if true <AlmuHS>he told me that my code needs a refactor, to be written "good" <jrtc27>well, GSoC is intended to benefit the project <jrtc27>so from his perspective why should he give up his time to help someone who doesn't want to listen to him and just wants to write poor quality code and move on? <AlmuHS>but I told him that, to write a good code, it's necessary a redesign, and the design can be very slow <jrtc27>we've had plenty of those in the past <jrtc27>and those have all resulted in the patches being abandoned <jrtc27>and thus being a complete waste of time, except for the student maybe <AlmuHS>I simply suggest him that, write a really good code requires a good design process <AlmuHS>but the design can takes many time, maybe not enough for GSoC <AlmuHS>so I suggested starts with little refactors <AlmuHS>but he was angry with me, because he defended that it was not necessary a design <jrtc27>I will say that it's easy for (a) people to not quite say what they mean (b) people to misunderstand each other <jrtc27>so without seeing exactly what was said, at this point it's just a game of he said she said <jrtc27>and it's hard for anyone external to form a judgement about what happened <youpi>that's unfortunately very true and very underconsidered, yes <jrtc27>I suspect, like it often is, both of you had your faults <AlmuHS>and, sometimes, I was not agree with some of his habits (little things, like how to map the table registers in a struct) and, when I told him politely, he was angry with me again <AlmuHS>he told me that I was despising their experience <AlmuHS>I don't despise his knowledge, I simply can disagree in some little things <jrtc27>I mean, saying things like that still doesn't help us know what happened <jrtc27>also (and don't take this the wrong way, it's not meant to be mean) you do occasionally say things in strange/hard-to-understand ways due to not being a native speaker, and that could have contributed to communication issues <jrtc27>e.g. maybe you meant to be polite but actually it didn't come across that way <jrtc27>(I find that more extreme examples of broken english on mailing lists can often come across as impolite, despite not being intended) <AlmuHS>Richard always told of me many times about my bad english <AlmuHS>It seems that he search a perfect developer which not exists <AlmuHS>and he seems don't approve any critique about his habits <AlmuHS>(if you follow the thread of the latest message that I shared here, you can notice It) <youpi>critiques which don't take into account what we have seen in the past are difficult to hear yes <youpi>including hastened source code is a way to get the Hurd less stable <youpi>which we have already suffered from in the past <youpi>and we probably still suffer from nowadays <youpi>which also produces bad impression <youpi>so yes, critique that doesn't take that into account, for instance, is difficult to hear <AlmuHS>the problem is the violence of some replies <AlmuHS>i don't know if I'm explain well <jrtc27>it's quite possible he lacks tack <AlmuHS>some newcomers has affraid about the violence of some replies <youpi>well, at some point when some point doesn't get through, one gets angry, yes, that's only human <youpi>and richard's patience level is not so high <jrtc27>tbh I'm surprised he's still around given he stopped working on the hurd years ago <AlmuHS>but I'm affraid that most of his replies are very violent, even contemptuous <youpi>I don't really see violence in his answers in that thread <jrtc27>I don't think that, I think he's just being blunt <youpi>and he expresses that, actually <youpi>smp is not something you can take lightly, and he warns about the dragons there <youpi>and, yes, I agree that something that isn't made long-term maintainable isn't serious <jrtc27>(though at least x86 has quite a strong memory model :)) <youpi>we have already enough of such code lying here and there <youpi>sometimes I do pick some of it to make it actually integrated <youpi>but I'd really not be just alone doing that cleanup work <jrtc27>I think that thread's a difficult one <jrtc27>I can see both perspectives somewhat <jrtc27>Richard's just quite blunt and so can come across a bit rude to those who don't know, even if he doesn't mean to cause offence <jrtc27>but to be fair to him your patches were quite poor quality a year ago, both in terms of how much they actually worked and in terms of the cleanliness of the code <jrtc27>so from his perspective he saw a student who had hacked something together without any real software engineering expertise <AlmuHS>there was more talks in private IRC, but I don't sure if I keep a backup <jrtc27>and it's very difficult to know at that point how willing and able you would have been to actually clean them up <jrtc27>because a little bit of refactoring wasn't going to make a meaningful difference to whether they could be merged or not <jrtc27>so why would he want to give up his time to do that, when the only good use of his time would have been on a student who would have reworked them into a mergeable state <jrtc27>especially when contrasted against some of the previous GSoC students <jrtc27>probably an element of "I will save my time for another year when a student more like those comes along" <AlmuHS>I remember a stupid discussion because I told him that I was not agree with map a table in a struct address to address, and I prefer group the registers which fills many address in an array. He was offended by that <AlmuHS>he told me that I was discounting its long experience <jrtc27>to me it sounds like a lot of that might be a communication thing <jrtc27>if he feels like you're just saying you disagree without having a discussion about why you each believe what you od <AlmuHS>I don't discount It, I simply disagreed in this simple detail <jrtc27>I'd be pretty offended if one of my students just turned round and said I was wrong <AlmuHS>he simply told me that I was discounting his long experience, and rejecting the judge of developers more experienced than me ***Server sets mode: +nt
<AlmuHS>I think that groups the registers which fills many address is important to improve the legibility and, even, ease some initialization using a loop <AlmuHS>putting each ISR register in a single field can results that this table will be many long <AlmuHS>I tried to explain it him, but he reject and reply that I've just told <jrtc27>that does seem like a strange thing to suggest <jrtc27>then again I wouldn't use a struct here at all, I don't trust them for device configs <jrtc27>as really you want to be using abstracted-away I/O functions to ensure it's all volatile and atomic <jrtc27>(FreeBSD would do it with something like `unsigned isr2 = bus_read_4(apic_dev, apic_local_unit + APIC_FIRST_ISR + i * APIC_REG_SIZE)`) <AlmuHS>using a struct, in this case, can prevent some errors in the calculus of the addressing shifting <jrtc27>it can, but it then leaves you at the whim of your compiler <jrtc27>for read-only(?) data structures like this it's probably fine <jrtc27>but if you say that something is a struct then it's free to read other fields from it as and when it wants <jrtc27>unless you add volatile everywhere, which is a whole misunderstood can of worms <AlmuHS>this structure is not fully read-only <AlmuHS>but I had many mistakes doing manual addressing like that `unsigned isr2 = bus_read_4(apic_dev, apic_local_unit + APIC_FIRST_ISR + i * APIC_REG_SIZE)`) <jrtc27>I mean, you trade one set of mistakes for another <jrtc27>and the "you invoked C UB" one is rather harder to debug <AlmuHS>but the struct also improves the legibility, in my opinion <jrtc27>so can the right set of functions and macros <jrtc27>writing to these fields changes things about the underlying hardware <jrtc27>and therefore has side-effects beyond "the value has changed if you read it back" <jrtc27>and so you need to tell it that or work around the fact that it doesn't generally model such things <jrtc27>most OSes have special functions you can use for doing side-effecting reads/writes <jrtc27>that tell the compiler "hey do exactly as I say because otherwise things will go wrong" <jrtc27>because atomics still have well-defined semantics in C that don't have side-effects <jrtc27>and the compiler is free to make assumptions based on that fact <jrtc27>anyway my point is you at least need volatile on the whole struct or its fields in order to stop the compiler breaking your code in subtle ways <jrtc27>it's still not how I'd do it as being intimately familiar with compilers and C semantics it makes me very nervous when you do anything even remotely "clever" like using a struct for hardware registers, but in practice it's probably fine and a lot of projects do that <jrtc27>though things get more interesting on other architectures once weaker memory models are involved... <AlmuHS>I'm from C++, and some practices are stranges for me <jrtc27>(in that volatile is still not enough) <AlmuHS>by example, in C++ devs prefers avoid the macros <jrtc27>C with templates would be an interesting language <jrtc27>macros do suck if you want to do anything advanced <jrtc27>though the GNU extension to let you use block expressions makes them significantly better <AlmuHS>`#define A 0` vs `const A = 0` was a interesting discussion in some C++ forums <AlmuHS>and the behaviour of enum in C is surprising <AlmuHS>return to macros, I'm surprised that in Mach there are C macros which implements assembly snippets <jrtc27>writing the same assembly over and over again gets boring and unmaintainable :) <AlmuHS>is it not possible to implement a assembly function? <AlmuHS>hasn't GAS includes a syntax to write functions? <jrtc27>the pattern I tend to see is that .macro only gets used local to a file (ie the file itself defines the macro), whereas preprocessor macros are used in shared headers <jrtc27>don't know why that is, maybe just because then it doesn't matter so much if C includes the header, so long as it doesn't use the macro it won't break <jrtc27>otherwise you need two disjoint sets of headers <AlmuHS>could be interesting to use auxiliary files to implement assembly functions or macros ;) <jrtc27>(well, with a common shared set) <jrtc27>I think also the syntax is just a bit uglier when you want to take arguments <jrtc27>and the preprocessor macros are more familiar to everyone <jrtc27>ENTRY/END and _C_LABEL are preprocessor macros defined in <machine/asm.h> <jrtc27>and save_registers/load_registers/do_ast are assembly macros defined in the file <jrtc27>writing long assembly snippets gets ugly in preprocessor macros with all the \'s and ;'s, so using .macro works well for them <jrtc27>and doing string manipulation for the labels is much nicer in the preprocessor <AlmuHS>I'm affraid about how to implement the assembly version of CPU_NUMBER() <jrtc27>if you have per-cpu data that's always available then it's easy <AlmuHS>yes, I will have to research about this <jrtc27>on x86 it's generally done with a segment register, which makes it a bit confusing <AlmuHS>because I even didn't know what is the exact GDT of Mach <jrtc27>on other architectures it's sometimes done with a normal reserved register <AlmuHS>and I don't know how to reserve a segment register in this <jrtc27>I have long since replaced that knowledge with other more useful things :) <jrtc27>but yeah, essentially you just want a GDT segment that always points at the CPU's per-cpu data <jrtc27>then you can just make %fs:0 or %gs:0 or whatever have the current cpu number <AlmuHS>the assembly snippet for jump to protected mode is the current ugliest code. Before implements the per-cpu data, I need to improve this snippet <AlmuHS>and I need to map correctly an address to put It in a safe way <AlmuHS>and maybe map the temporary GDT too <jrtc27>even on nicer architectures that kind of code is never pretty... <jrtc27>but you don't necessarily need to set up the segment that early <jrtc27>you can defer it to later so long as you just do it before the first time it's needed <jrtc27>and might help preserve your sanity <AlmuHS>in next stage, about cpu enabling and basic config, I need to safe many things <AlmuHS>map the assembly snippet and the temporary GDT, at first <AlmuHS>and clean the assembly snippet to remove some garbage <AlmuHS>I also will need to serialize the cpu starting, to avoid many cpus accessing to the assembly snippet at same time <AlmuHS>maybe I can need to damo22, to configure the APIC timer, because the current delay() function is a dirty while loop <AlmuHS>/* Someone with time should write code to set cpuspeed automagically */ <AlmuHS>#define DELAY(n) { volatile int N = cpuspeed * (n); while (--N > 0); } <AlmuHS>this is a very unsafe delay() >:o <jrtc27>ehhh OSes do that reeeeeeeeeally early in boot before they have a timer <jrtc27>but yeah you should use a real timer as soon as you can in boot <AlmuHS>if damo22 gets to configure APIC timer, I can get a good timing to control properly the IPI sending <AlmuHS>because I need be sure that 1 ms is really 1ms <jrtc27>yeah you'll want to have the timer before you start IPI'ing to bring up the APs <AlmuHS>and maybe could be useful find a semaphore <AlmuHS>to serialize the cpus enabling as a safe way <jrtc27>eh, generally you want to use mutexes or spin locks (depending on the workload) <jrtc27>semaphores aren't so efficient to implement <jrtc27>(and are also harder to use correctly) <AlmuHS>yes, a mutex can be a good alternative <AlmuHS>and, the latest thing will be extract the code to configure paging (currently in i386at_init() function) to separate functions, to avoid repeat the same code in the APs ***Server sets mode: +nt
***Server sets mode: +nt