User talk:Love4boobies

ACPI content deletion

Why did you undo my edit to FADT? You said that it didn't use C types. But it uses the same types used in RSDT and RSDP. Moreover you can't use C types to describe a 64 bit type for example. It would be unsigned long long on x86, and unsigned long on x86_64, so a typedef like QWORD is justified IMO. And could you please explain the "serialization" problem? Alfaomega08

You can. Use <stdint.h> and you get uint64_t et al. -- Solar 16:25, 10 March 2011 (UTC)

You can't do that in ANSI C, nor you can in C++, so <stdint.h> is close to useless for anyone who can't or don't want to use C99 features. -- Fanael 17:38, 10 March 2011 (UTC)

Solar is correct and it's what I meant by that. As for serialization, it was also explained in the description. It is important to learn C before writing an OS in it. Structure fields may have gaps between them, they are not like arrays (e.g., because of alignment requirements or cache optimizations). --Love4boobies 17:11, 10 March 2011 (UTC)

Do you mean I should put an __attribute__((packed)) at the end of the structure? If that's the problem, I skipped it because 1) it's not cross-platform 2) I think it is given for granted that any structure in os development should be packed. -- Alfaomega08 17:22, 10 March 2011 (UTC)

No, that's not what I meant. Here are a couple of links to get you started: Serialization, required knowledge to starting an OS. --Love4boobies 17:38, 10 March 2011 (UTC)

Well, I know what serialization is, and I'm quite sure to have the necessary skills to program an OS, however I still can't see how "Structure fields may have gaps between them" fits in the picture, as the packed attribute should remove all those gaps... -- Alfaomega08 17:33, 10 March 2011 (UTC)

Except we both agreed that using __attribute__((packed)) isn't portable across C implementations. If you know what serialization is, learn how to do it (or at least apply some of the concepts) in C as well :) --Love4boobies 17:38, 10 March 2011 (UTC)

int*_t and uint*_t are standard C, and are also the only official standard. If we want to adhere to a standard, we lterally have no choice. If you suffer from NIH or don't want to adhere to a standard, you just typedef them in a header of your own. "word" and "doubleword" are not a standard - on many non-intel platforms a word means 32 bits instead of 16. Also, the packed attribute should be added since the structure expects it to be that way. If you something non-standard (read: non-gcc) you should know how to substitute it. It's better to have things work out-of-the-box for 95% of the community, or have everybody (forget to) make their own fixes by lacking a standard altogether. Now, can we get this over with? The pendant votes and flames aren't helping anyone.

Back to the thing that started all this: I was shocked by the deletion. If you disagree, fix it, but deleting a page full of correct and useful information is about the worst decision you could make on a wiki. Rollback and karma /= 2; to you. - Combuster 22:34, 10 March 2011 (UTC)

I was going to rewrite that but in the meantime didn't want the wiki to have incorrect information. Picking up on the fact that words and dwords are 16-bit and 32-bit, respectively, is easy. On the other hand, using an unpacked structure is a bit more subtle---this is why the code was broken. Can I haz karma back? --Love4boobies 06:36, 11 March 2011 (UTC)

If you get into a situation like this - a Wiki article containing partially false information but the correction being non-trivial - add a note about the problems with the information, and a link to where you are doing the rework. Once the rework is done, copy it over to the article in question. Don't delete info and rewrite it "later", because - you guessed it already - later never comes. -- Solar 09:05, 11 March 2011 (UTC)

I see your point but I think the community needs to agree on a more formal protocol or something because common sense is slightly different for everyone (e.g., I would rather not have information that's slightly wrong and assume it correct in a situation like this). It's not really productive for us to argue about such matters. Btw, the problem is still not solved but hopefully I, or someone else, will fix it soon (and not later) :) --Love4boobies 09:16, 11 March 2011 (UTC)

This is the "formal protocol" (as much as such a thing exists) on knowledge Wikis: Annotate, rewrite in scratch namespace, replace. Slightly wrong information with a note what *is* slightly wrong about it is better than no information at all. Nothing ever is perfect, that's the Wiki creed. I don't want to argue, I'm just pointing out. -- Solar 09:34, 11 March 2011 (UTC)

As such, I see two solutions for the FADT page: add a note / comment that you're "assuming packed structures", or (even better) describe the data structure layout in text instead of code. (That way it's just as helpful for e.g. our Pascal friends, and we're not risking anyone doing the copy & paste.) That really should do it, IMHO. I'd do it myself, but I have no stocks in the subjects anyway. ;-) -- Solar 09:40, 11 March 2011 (UTC)

Google Docs link broken

The link to the AMD64 ABI for UDI draft on the main page is currently broken, seemingly by the Google Docs to Drive transition. Is there still a copy somewhere? --Alexshpilkin 16:09, 10 March 2014 (CDT)

Hi. Sorry for the delay. You can find a copy here. --Love4boobies 06:21, 9 July 2014 (CDT)

Copied from Wikipedia for no reason

Actively objecting the deletion, please read the discussion here --Lexected 16:27, 30 April 2017 (CDT)

Actively objecting the objection. It seems that the only reason you want to provide details for an internal tool (used by COSMOS and nobody else) is publicity. In other words, I don't see how this is not spam. Brendan 16:49, 30 April 2017 (CDT)

It's not related to OS development. Furthermore, what is the point of mirroring a Wikipedia article here? It's already there and all our version will achieve will be to quickly go out of sync with the original. EDIT: Oh, even Wikipedia doesn't want it so this is clearly PR. --Love4boobies 19:00, 30 April 2017 (CDT)