Embedded weblog - Tag - bsd

decreasing the size of the distribution [OpenBSD]

2009-10-26T17:21:00+01:00

Voilà qu'aujourd'hui, sur la ML d'OpenBSD, quelqu'un cherche à faire baisser la taille d'OpenBSD tout en gardant les fonctionnalités (réseaux) dont il a besoin. C'est trivial sous Linux, mais avec le poisson qui pique, c'est une autre affaire. Comme toujours sur cette mailing list, le pauvre se fait gentiment éconduire ; florilège :

I'd suggest spending the additional ~$2 for the 1GB flash and not to mess with anything!

Lastly if you do build a little shrip frankensystem, asking for help here isn't going to get a lotof sympathy. You'll be on your own.

If you have to ask, you shouldn't be doing it. Why would you possibly need to get smaller than the baseXX, etcXX and manXX sets? These easily fit on a few hundered MB. What modern flash disk won't fit this?

Ah ces barbus, ils sont formidables, et toujours au fait de ce qui se passe dans la vraie vie de tous les jours. Soit le monde de l'embarqué, où il n'est guère décent de proposer une distribution de 512Mo qui embarque les pages man autant que le fabuleux répertoire /usr/share/misc/, qui pour 7,2Mo propose la liste complète des aéroports dans le monde (fichier airports), ou les codes postaux aux États-Unis (zipcodes) ; bon, je suis méchant, il faut garder à tout prix terminfo.db (3,0Mo), mais on peut bazarder termcap.db (2,7Mo).

Il existe deux projets qui se proposent cependant de passer outre la religion inflexible du "touche à rien" (un autre concept de la geek-attitude) : flashdist et soekris (il y eut aussi flashboot). Mais voilà : basées sur des scripts qui copient les fichiers nécessaires à la nouvelle distribution réduite depuis le système de fichier de la distribution courante vers un répertoire donné (avant de l'intégrer dans un master), leur méthode est clairement de type top-down. Pour du bottom-up, c'est-à-dire de la compilation des sources pour obtenir le firmware (ou le master, à savoir le firmware plus le bootloader et d'autres partoches qui servent à stocker par exemple de gros fichiers, ce qui en soit justifie de réduire la taille de la distrib' -- qui pèse plus de 250Mo quand on ne met que le package "base", celui qui contient tellement peu de choses réellement utiles qu'on est rapidement embêté), j'ai bien peur que ce soit une autre paire de manches.

5.2 - Why do I need to compile the system from source?
Actually, you very possibly do not.
Some reasons why NOT to build from source:
     * Compiling your own system as a way of upgrading it is not supported.
     * You will NOT get better system performance by compiling your own system.
     * Changing compiler options is more likely to break your system than to improve it.

Et c'est sans compter le système de mise à jour assez rudimentaire (euphémisme) du firmware proposé par nos deux solutions :

You now need to take the image file and write it to your compact flash device using dd. Make sure you are using the correct device otherwise you can blow away your hard-disk or other devices.
dd if=image_cf of=/dev/??? bs=1k

(pour faire bref : tu démontes ton serveur, tu enlèves la compact flash, tu la branches dans ton adaptateur universel, et après tu ne te trompes surtout pas de device où copier comme un gros cochon, sinon tu risques de flinguer des trucs pas bons, style ton disque dur -- c'est super industriel comme procédé, je me vois bien proposer ça à un client)

Oh, il y a des recettes pour faire ça dans son garage, mais pour des applications industrielles, ça reste assez vague. "Homemade Embedded BSD Systems" et "Embedded OpenBSD" sont dans le genre de bonnes intros, mais on est loin du compte.

Ou alors, il y a Linagora. Et en plus, vous ne serez même pas mal accueilli (et on s'étonne que je n'aie jamais laissé de messages sur cette ML...). Et en plus, le firmware peut être mis à jour à chaud, et on peut revenir en arrière en un clin d'oeil. Et en plus... Ah ah, il faut garder des surprises ! :)

au détour d'une macro crasseuse

2009-05-27T16:55:00+02:00

#define ATOI2(ar) ((ar) += 2, ((ar)[-2] - '0') * 10 + ((ar)[-1] - '0'))

Ça se trouve au milieu de date.c, de l'utilitaire date d'OpenBSD. Ça transforme tout nombre entre 10 et 99 (ou 00 et 99) en chaîne de caractère en integer (ou au moins en char), et ça passe même sur un gcc très récent. Outre l'idée d'avancer de deux dans le pointeur puis de référencer en négatif, et de flinguer au passage la variable d'entrée, autre chose interpelle : la syntaxe.

int i = 42;
int t = (2, i++, 4 + i);
printf("%d ", t);

Ceci affiche 47 !! Page 210 de votre K&R (A7.18), opérateur "," :

f(a, (t=3, t+2), c)
a trois arguements et le deuxième d'entre eux vaut 5.

Toutes les personnes interrogées, développeurs expérimentés en C, ne connaissaient pas ; je me suis senti moins seul...

berk, berk, berk

2008-10-14T16:07:00+02:00

int lm_match(struct lm_softc *); int wb_match(struct lm_softc *); int def_match(struct lm_softc *); struct lm_chip { int (*chip_match)(struct lm_softc *); }; struct lm_chip lm_chips[] = { { wb_match }, { lm_match }, { def_match } /* Must be last */ }; void lm_attach(struct lm_softc *sc) { u_int i, config; for (i = 0; i < sizeof(lm_chips) / sizeof(lm_chips[0]); i++) if (lm_chips[i].chip_match(sc)) break;

J'ai remis bout à bout les bons morceaux, dans la réalité, c'est bien plus espacé, sinon se serait trop lisible... (on remarquera que j'ai tout de même laissé les commentaires d'origine)

était-ce du second degré ?

2008-07-08T12:13:00+02:00

S'il y a bien une ML qui tend régulièrement vers le grand n'importe quoi, c'est celle d'OpenBSD. Perle de ce matin (échange d'hier en fait) :

Subject: "How to undelete?"

I deleted a directory from an OpenBSD slice from my 2nd HD, and I need
to recover a single file.

I tried : http://myutil.com/2008/1/15/undelete-unrm-for-openbsd-4-2-with-dls
but failed :

# dls /dev/wd1x > /xxx/xx/undelete.bin
Sector offset supplied is larger than disk image (maximum: 0)

Première réponse :

You use a backup.

UNIX != Windows != OSX

Très utile, n'est-ce pas ? Mais le plus drôle est à venir :

Just open your disk in a hex editor and look for your data, it should be here.

Là, c'est très fort. Finalement, la première réponse n'était pas si mauvaise que ça... Mais notre gars manifestement trouve cette idée plutôt à son goût :

Which hex editor do you advise?
Should I have to umount the partition before?
the partition is 40 GB size on a secondary disk, OpenBSD old slice,
should I need at least such space (/tmp ?) to open it on the hex editor
from my OpenBSD 4.3?

Thanks!

Pour rappel, sous Linux, y'a entre autres (et surtout) Photorec, et c'est plus classe que l'ancêtre debugfs. Attaquer à l'éditeur hexadécimal, c'est tellement du grand n'importe quoi que je ne pense même à avoir à rappeler comment marche la fragmentation... (en revanche, si votre Firefox plante alors que vous écriviez un mail, je vous recommande un grep -a sur /dev/mem, mais c'est pas pareil)