Remove shared or move libkmod-list.c into shared

Aperta
  • Qualcosa non va?
#232 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
10/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
c, linux
Ambito
operating-systems

Direzione di ricerca

The question is where kmod_list code should live: depmod includes libkmod-internal.h to reach the list functions in libkmod/kmod_list.c, and the issue weighs moving them into shared/ against a larger reorganisation. Read the two proposed options and the linked config-handling issue to see the trade-offs. Done means the maintainers pick one layout and agree how depmod should get its list helpers, not that code is written.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Right now, depmod includes libkmod-internal.h to access kmod_list functions, which are supposed to be used within libkmod. They are not exposed through libkmod.h, i.e. they are not part of the public API.

This could be fixed by moving kmod_list.c as list.c into shared, getting rid of libkmod-internal.h usage in depmod. At first, I would have preferred this solution.

But when I looked into config: move config handling to shared/, I noticed that configuration handling uses error logging, accessing ctx for correct logging function etc. This would definitely drag kmod-specific logic into shared, which is currently very independent code.

If we move out the error logging, we would have to repeat the error handling in libkmod-config.c and depmod. Rather easy to do, just duplicated logic again.

Should we expose libkmod functionality to tools, just like we do with libkmod-internal.h in depmod right now, we would also get rid of duplicated instructions in kmod and libkmod, i.e. we would get a smaller binary.

So these are my proposals. Would like to get some feedback which one is preferable.

Option 1
  1. Move code used in libkmod from shared into libkmod directory (array.c becomes kmod_array.c and all functions get kmod_ prefix)
  2. Move code exclusively used in tools from shared into tools directory
  3. Create a libkmod-shared.h file in libkmod
  4. Include libkmod-shared.h in libkmod-internal.h
  5. Include libkmod-shared.h in tools where needed

This will further reduce the binary size, since commonly used code actually exists only once as machine instructions. The kmod tools have more access into the library than other programs could (which makes them rather dependent on libkmod internals even if public API is stable).

Option 2
  1. Move kmod_list.c from libkmod into shared (kmod_list.c becomes list.c and all functions lose their kmod_ prefix)
  2. Create shared/list.h
  3. Replace libkmod-internal.h in depmod with shared/list.h and libkmod.h

This keeps utility code separated from business logic. The kmod tools have same limitations and are as independent from libkmod internal changes as every other program which utilizes libkmod.

Lingua principale
C
Stelle
116
Fork
70
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di kmod-project/kmod

Tutte le issue di kmod-project/kmod

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.