Vlákno názorů k článku
Čištění kódu x86 APIC, vývojář volá: zbavme se 32 bitů
od gaston68cz - Ono to udržování 32b už opravdu ztrácí smysl...
-
Ono to udržování 32b už opravdu ztrácí smysl protože do 14 let musí všechny tyto systémy stejně zmizet. Zatím se o tom moc nemluví, asi je to pro většinu lidí daleko, ale důvod je jednoduchý: 19. 1. 2038 03:14:07 GMT.
Tedy okamžik kdy na 32b systémech s 32b time_t příští sekundou nastane 13. 12. 1901 20:45:53 GMT. -
Neexistuje důvod, proč by 32-bitový systém nemohl mít 64-bitový typ
time_t, jen to zabere trochu víc místa a některé operace budou trvate déle, ale to je holt život. Problém je spíš s existujícími komunikačními protokoly a datovými formáty, kde jsou natvrdo 32-bitové časové známky (případně jejich obdoba), ale ten se týká úplně stejně i 64-bitových systémů. -
Teoreticky máte pravdu, SUS váže time_t na long a není důvod proč by na 32b systému nemohl být long 64-bitový. Kdysi jsem to dokonce považoval za logické - tedy že na 32b systému je short 16b, int 32b a long 64b.
Jenomže v reálu mi v minulosti prošlo rukama dost 32b *nix systémů a nevzpomínám si na jediný kde by byl 64b long. Pravda, všechno to byly serverové / desktopové OS, s řídícími systémy jsem se nesetkal takže tam nevím. Ale protože předpokládám že důvod implementace longu na délku slova procesoru je ve výkonu tak bych nečekal že u nich to bude jinak, ale to by mohl posoudit spíš někdo kdo s nimi pracuje.
A platilo to i pro Win ale s těmi naštěstí už dlouho nemám co do činění. Nicméně pokud tu někdo zmiňoval řídící systémy ve zdravotnictví založené na 32b WinXP tak tam bych to viděl jako reálnou hrozbu. A pokud vím tak např. bankomaty jsou to samé. -
Ale jsme zas u toho:
Namisto toho, aby tvurce takoveho udelatka nasadil proste aktualni mainline a userspace, ktery resi problematiku prechodu 32 na 64 bit unixtime komplexne, tak je situace tahle (z duvodu, ze puvodni platforma nebo nektere device drivery tam uz nejsou):
Nekde se musi vyhrabat sada patchu ktera prinesla 32->64 prechod (vsechny promenne, novy syscall), pak to musi nekdo pretvorit na starou verzi kernelu, ktera v tom udelatku byla. Po nasazeni se zjisti, ze je treba udelat omnoho vice - treba userspace hwclock tool, nebo hardcodovat dalsi epochu. Takze vznikne nejake bastl reseni / nedokonaly hack. A to nemluvim o padajicim glibc, ktery je taky sprazen bud s 32b nebo 64b casovanim a syscally.
Jop.. zazil jsem tu dobu kdy byl kernel napred ale muj userspace nikoliv a dost jsem se divil ze takova blbost jako timestamp nesla resit lepe, kdyz se o problemu vedelo.
Bohuzel stav, ze vse se vsim souvisi a neexistuje stabilni verzovane API, ktere by mohli koexistovat zaroven, protoze vzdy jsme v nejakem prechodnem obdobi nenahrava dobremu jmenu.
Tento smer ale adopovali nedavno i W10/W11, kde kdyz tvorite drivery, tak mate s tim porad praci i kdyz se u vas nic nemeni. Pritom vypadavaji moznosti, ktere tam predtim byly a uz nejsou. Plus neustale zmeny ve zpusobu podepisovani, atd.
-
Tady máte prostě jenom dilema, kdo ty náklady na vývoj ponese.
Buď to bude "platit" vývojář driverů, protože se mu bude měnit api jádra.
Nebo to budou platit vývojáři jádra, protože budou muset udržovat X starých verzí. A navíc ty staré verze budou formovat další vývoj, protože některé změny do nich promítnout prostě nepůjdou.Jo, Microsoft na tu zpětnou kompatibilitu hodně tlačil. A díky tomu je i nejnovější winapi totální hnus. Protože i nová funkčnost musí brát v úvahu zkamenělé rovnáky na vohejbáky z dob 16b intelů. Tohle taky nenahrává dobrému jménu, jen u jiné skupiny lidí.
-
To mi připomnělo původní hru Transport Tycoon Deluxe. Jednou (už je to dávno, člověk měl čas na hraní) jsem totiž dosáhl u své společnosti na účtu částky £2,147,483,647. Hra kupodivu nespadla a ani to nepřeteklo do záporné hodnoty. Jen hodnota společnosti najednou spadla až někde "do pekla" na -£2,147,483,648 . Obě hodnoty při dalším hraní zůstávaly stejné bez ohledu na to, co člověk dělal. Trochu jsem měl strach aby mne nekoupil nějaký konkurent ale tehdejší "AI" to neměly ve zvyku :-)
