mboost-dp1

Linux

Microsoft lover mere hjælp til Hyper-V understøttelse i Linux

- Via Version2 - , redigeret af Emil , indsendt af arne_v

En del kiggede en ekstra gang, da Microsoft i juli bidragede 20.000 linjer kode til Linux-kernen for at øge kompatibiliteten med deres Hyper-V virtualiseringsplatform.

Siden bidraget har det dog været småt med involvering fra Microsofts side, så lidt, at Linux-udvikler Greg Kroah-Hartman på sin blog skriver, at hvis de ikke snart hjælper, så vil koden blive fjernet fra kernen igen.

Kroah-Hartman har selv lavet over 200 patches til Microsofts kode, og hos Microsoft erkender man nu, at der skal ske noget. Version2 har haft en snak med Hank Janssen, leder af Microsofts Open Source Technology Center, og han kan bekræfte, at Microsoft har været for passive i sagen, men at det nu vil ændre sig.

Hank Janssen til Version2 skrev:
Jeg har personligt brugt meget tid på at gennemgå de mere end 200 ændringer, og det tager tid. Men Gregs kritik er absolut gyldig, og det får også den konsekvens, at jeg selv inden for den næste uge eller to vil ændre min rolle til at fokusere på Hyper-V-integrationen i Linux-kernen.

Janssen har ifølge Version2 allerede taget kontakt til Kroah-Hartman.





Gå til bund
Gravatar #1 - eliasr
9. sep. 2009 07:57
Den gang mente jeg det lød lidt "buggy" at lade microsoft kode :P og jeg fik da lidt ret
Kroah-Hartman har selv lavet over 200 patches til Microsofts kode

men det kunne jo være så lidt som en enkelt linje per patch, så helt galt er det heldigvis ikke gået.

For linuxbrugerne's skyld håber jeg de får det færdigt snart
Gravatar #2 - Anders Lund
9. sep. 2009 08:06
eliasr (1) skrev:
men det kunne jo være så lidt som en enkelt linje per patch, så helt galt er det heldigvis ikke gået.


Ja - eller et enkelt tegn. :-)
Gravatar #3 - Azjo
9. sep. 2009 10:29
eller måske kun en bit ;)
Gravatar #4 - Tore
9. sep. 2009 10:30
Linux kernen er næsten lige så fuld af bugs som Windows kernen divideret på antal linjer kode.. Det handler om kompleksitet, som er over et menneskes fatte evne..

Det der altid har irriteret mig mest ved Linux, er den ofte komplette mangel på code review.. syntes der slipper alt for mange dårlige programmer ind i repositoriet, BSD er lidt bedre på den front men ikke meget..

Ville være rart hvis Gentoo og Debian grupperne ville lave et stempel om at dette program er blevet reviewet og lever op til kravene, så man ikke får alle de her buggy installationer ind.
Gravatar #5 - GurliGebis
9. sep. 2009 11:46
Tore (4) skrev:
Ville være rart hvis Gentoo og Debian grupperne ville lave et stempel om at dette program er blevet reviewet og lever op til kravene, så man ikke får alle de her buggy installationer ind.


Det vil kræve alt for meget (og jeg ved fra Gentoo i hvert fald, at der ikke er ressourser til det).
Desuden, skulle de folk som står for vedligeholde pakkerne så lave review på koden, eller hvem skulle?

Normalt fungerer det sådan (i Gentoo i hvert fald), at hvis en pakke kommer fra en stable branch fra udgiveren, og der ikke har været nogle bugs omkring den i en længere periode (over en måned), så vil den kunne gå stable.
Gravatar #6 - arne_v
9. sep. 2009 12:50
eliasr (1) skrev:
Den gang mente jeg det lød lidt "buggy" at lade microsoft kode :P og jeg fik da lidt ret


Egentligt ikke.

Det er ikke funktionelle bugs men overtrædelser af coding convention og manglende brug af standard kode der rettes.

I debatten på V2 gives der et eksempel på hvad det drejer sig om.

typedef void VOID;
VOID foobar();

versus

void foobar();

I dette tilfælde kan jeg dog godt følge Linux kernel coding convention - den VOID er ret absurd.

Men der er andre lidt mere specielle krav.

Læs selv på:
http://www.linuxjournal.com/article/5780

Indrykning på 8 med TAB fremfor spaces? Bvadrrrr !
Gravatar #7 - Windcape
9. sep. 2009 14:55
#6

Ja, det er lidt tuderi. Et ordenligt IDE kan da rette det på ingen tid, og lidt search&replace resten.

200 patches er ret overdrevent, og at kommentere på kodens værdi ud fra dens code-convention er dybt latterligt.
Gravatar #8 - arne_v
9. sep. 2009 14:58
#7

Jeg kan såmænd godt forstå at GKH er sur over, at han skal lave de rettelser fremfor MS.

Linux kernel coding convention er ikke ligefrem hemmelig.

Min pointe var bare, at det ikke var 200 bugs.
Gravatar #9 - Windcape
9. sep. 2009 15:03
arne_v (8) skrev:
Jeg kan såmænd godt forstå at GKH er sur over, at han skal lave de rettelser fremfor MS.
Der er jo ingen reel tvang. Han vil absolut bare kigge på syntax, istedet for funktionalitet til at starte med.

arne_v (8) skrev:
Min pointe var bare, at det ikke var 200 bugs.
Helt klart.

Er der forresten nogen grund til at benytte typedef VOID istedet for void?
Gravatar #10 - Kazper
9. sep. 2009 15:27
Windcape (9) skrev:
Der er jo ingen reel tvang. Han vil absolut bare kigge på syntax, istedet for funktionalitet til at starte med.


Det er hamrende vigtigt at overholde syntax - også før funktionalitet. Lader du først syntaksen flyde vokser det hurtigt til en enorm opgave at rette det til senere, og det kan på sigt alvorligt påvirke overskueligheden - og dermed muligheden for at rette funktionalitet.

Dermed ikke sagt at jeg har nogen anelse om hvor relevant Linux kernel coding convention er - eller hvor vigtige eller ligegyldige GKH's rettelser er, for det har jeg slet ikke kigget på. Men udfra at MS selv siger at manden har ret vælger jeg at tro han har en helt ok pointe her...
Gravatar #11 - arne_v
9. sep. 2009 16:00
Windcape (9) skrev:
Der er jo ingen reel tvang. Han vil absolut bare kigge på syntax, istedet for funktionalitet til at starte med.


Nu er det ikke syntax men coding convention (coding style).

Syntax fejl skal fixes inden skidtet compiler.

Men i store projekter er det ret vigtigt at man konsekvent følger coding convention.

Så som ansvarlig for det område af Linux kernen er det hans ansvar at den kode der checkes ind overholder coding convention.
Gravatar #12 - arne_v
9. sep. 2009 16:07
Windcape (9) skrev:
Er der forresten nogen grund til at benytte typedef VOID istedet for void?


Ikke nogen jeg kan komme i tanke om.

Den principielle fordel er at man senere kunne ændre VOID til at betyde noget helt andet senere.

Men det ville jo vaere en absurd ændring.

Gravatar #13 - arne_v
9. sep. 2009 23:19
#6

Et hurtigt kig i winnt.h viser iøvrigt:

#ifndef VOID
#define VOID void
typedef char CHAR;
typedef short SHORT;
typedef long LONG;
#endif

så lige netop VOID er nok en #define og ikke en typedef.

Men det bliver det jo ikke bedre af.
Gravatar #14 - Windcape
9. sep. 2009 23:22
Det lyder underligt. Måske har de bare sakset en del af koden fra Windows Hyper-V driveren, og omskrevet den så den virker?
Gravatar #15 - arne_v
9. sep. 2009 23:59
#14

Måske. Men jeg tvivler. Drivere i Windows og Linux har vist ikke så meget til fælles.

Jeg tror mere på at det er vanen. MS's C/C++ programmører er vant til ders typedefs, ungarsk notation o.s.v..
Gravatar #16 - Windcape
10. sep. 2009 00:24
arne_v (15) skrev:
Drivere i Windows og Linux har vist ikke så meget til fælles.
Type definitioner af strukturer osv. burde vel netop være ens?

arne_v (15) skrev:
Jeg tror mere på at det er vanen. MS's C/C++ programmører er vant til ders typedefs, ungarsk notation o.s.v..
Sikkert. Ikke at de er så forskellige fra alle andre.

Jeg har kigget på QT (KDEs GUI bibliotek). Det er ligeså skræmmende som WinForms.

Og GTK var heller ikke bedre, heh.

Der er noget i C/C++ som opfordre folk til at kode super grimt. Et eller andet sted.
Gravatar #17 - arne_v
10. sep. 2009 00:30
#16

Der er mange typedefs som er unikke for Win32 API.

Og ungarsk notation er heller ikke udbredt uden for Windows verdenen.
Gravatar #18 - arne_v
10. sep. 2009 00:35
#16

Grimt er et meget subjektivt udtryk.

Ethvert sprog har sine paradigmer og idiomer.

Det har C og C++ også (ikke de samme dog!).

Man kan lave noget meget ulæseligt kode i de sprog.

Men C er altså opfundet til at skrive styresystemer i. Det kræver adgang til en lang række assembler lignende features.

Det gør ikke C til et dårligt sprog. Det løser den opgave som det er designet til. Hvis folk bruger det til noget som det ikke er egnet til, så er det ikke sprogets skyld, men udviklernes.

C++ valgte at være 99% C kompatible. Det var et valg man traf. Der var gode grunde til det valg dengang først i 1980'erne.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login