Donc je comprends Linus qui ne veut pas tout de suite d'un code qui fait en sorte que du matos ancien qui marchait ne marche plus.
Je ne parle pas du tout de l'API coté hard c'est à dire des différents pilotes qui initialisent le bus IDE et qui se chargent de reprendre les infos du BIOS, mais de la couche d'abstraction qui permet de finir l'initialisation du disque, d'en régler la vitesse et d'interagir physiquement avec les différents périphériques du bus de façon générique.
En ce qui concerne la perte de données potentielle, une fois qu'un disque a été initialisé avec le bon nombre de têtes et de cylindres et qu'il est accessible via les IRQs et autres appels systèmes, c'est le boulot de la couche encore au dessus (à savoir les pilotes file system)
Pour finir, ce n'est pas que Linus ne veut pas tout de suite d'un code qui bousille le matos ancien, mais c'est qu'on se retrouve au contraire avec une seule API bas niveau (ici SCSI) qui gère deux types de matos très différents. On se retrouve donc à voir arriver dans l'API SCSI des modifs qui ne servent qu'au SATA (Genre les patchs bien gruik sur IO_WAIT_SCAN). Donc loin de préserver une API sensible des modifications, on se retrouve à ajouter des verrues dans une API éprouvée pour palier à des bugs de chipsets peu répandus...
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Jerome Herman . En réponse au journal Participer un développement de Linux. Évalué à 7.
Je ne parle pas du tout de l'API coté hard c'est à dire des différents pilotes qui initialisent le bus IDE et qui se chargent de reprendre les infos du BIOS, mais de la couche d'abstraction qui permet de finir l'initialisation du disque, d'en régler la vitesse et d'interagir physiquement avec les différents périphériques du bus de façon générique.
En ce qui concerne la perte de données potentielle, une fois qu'un disque a été initialisé avec le bon nombre de têtes et de cylindres et qu'il est accessible via les IRQs et autres appels systèmes, c'est le boulot de la couche encore au dessus (à savoir les pilotes file system)
Pour finir, ce n'est pas que Linus ne veut pas tout de suite d'un code qui bousille le matos ancien, mais c'est qu'on se retrouve au contraire avec une seule API bas niveau (ici SCSI) qui gère deux types de matos très différents. On se retrouve donc à voir arriver dans l'API SCSI des modifs qui ne servent qu'au SATA (Genre les patchs bien gruik sur IO_WAIT_SCAN). Donc loin de préserver une API sensible des modifications, on se retrouve à ajouter des verrues dans une API éprouvée pour palier à des bugs de chipsets peu répandus...