Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exposer les partitions d'un block device #176

Open
NicolasFloquet opened this issue Dec 7, 2013 · 2 comments
Open

Exposer les partitions d'un block device #176

NicolasFloquet opened this issue Dec 7, 2013 · 2 comments
Assignees
Milestone

Comments

@NicolasFloquet
Copy link
Member

Donc suite à nos discussions, on a décidé qu'au moment du register_blk_device, on va s'occuper de créer des fichiers pour chaque partition du block device.

tl;dr: ça va pas marcher.

Il faut que la partie qui s'occupe de ça soit capable de lire le MBR. Déjà, on est pas sur qu'au moment où on va essayer de lire le MBR si le disque est vraiment initialisé. Par exemple si le mec qui code le driver met le register au début de l'initialisation du driver (ouais il est con mais admettons) ça va pas marcher du tout. D'autre part, tout ça ne marcherait que si la lecture est totalement synchrone. Pour peu que le driver se base sur un thread séparé pour la lecture (ce qui va être souvent le cas), on sera définitivement bloqué.
Bref, je vois pas trop comment faire. Une solution que je vois serait d'avoir un service kernel qui est activé dès qu'un block device apparait, et qu'il crée les partition quand c'est possible. De cette façon on ne risque pas de situation de blocage je pense...

@MaximeCheramy
Copy link
Member

Je ne suis pas sûr d'avoir compris à 100% les problèmes, je propose qu'on en discute par IM pour essayer de trouver une solution.

@NicolasFloquet
Copy link
Member Author

J'ai commencé à travailler la dessus.
Mon approche pour le moment c'est de faire un blkdev qui fait un passe plat des interfaces du driver, avec un ajout d'offset pour les read et write.
Pour que le driver soit capable de savoir à quel blkdev sous-jacent il doit s'adresser, je vais modifier devfs pour que chaque device enregistré ai un numero d'inode unique, et que ce numero soit retourné par les méthodes register_chardev et register_blkdev.

Au delà de cette feature là, ça permettra à tous les drivers d'être multi-instanciés beaucoup plus facilement.

Par exemple, floppy est instancié deux fois (fd0 et fd1) Pour le moment on fournis une structure blkdev_interface différente pour chaque instance. Désormais, il sera possible d'avoir une interface unique, et de savoir quelle instance du driver est adressée grace au numéro d'inode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants