Re: [make-initrd] master updated

["Michael A. Kangin" <mak@complife.ru>]

On 04/29/2019 04:49 PM, Alexey Gladkov wrote:

>>> root=/dev/nfs это не моё изобретение:
>>> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46
>>
>> Я просто задумался, если NFS (и другие фичи) рассматривать и как
>> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи
>> наверное есть :)
> 
> В каком смысле чей будет ?

Мм, мне трудновато с непривычки выразиться корректно и понятно :)

Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут и 
использовать друг-друга в качестве промежуточного транспорта - как они 
договорятся, которая из них будет обрабатывать параметр root=?


Ну вот допустим есть некая фича "squash-boot", которая использует 
nfsroot как транспорт. Мы говорим root=/dev/nfs, чтобы у нас nfs вообще 
заработало. Тогда этой squash-boot мы должны дать какой-то другой 
параметр вместо root= ?

Хорошо, допустим мы ей будем давать squash-root=
А в ситуации, когда "squash-boot" будет пользоваться как транспортом 
http или iSCSI - мы вообще без root= останемся?


Или разделить нынешнюю nfsroot на транспортную фичу, которая будет 
хотеть nfsroot= и непосредственно монтировочную (как бы назвать такую 
финальную фичу - которая предоставляет подготовленный /root), которая 
будет активироваться root=/dev/nfs?

т.е. например если мы скажем
nfsroot=192.168.0.1:/nfsshare/mysystem root=/dev/nfs
то, как сейчас, 192.168.0.1:/nfsshare/mysystem смонтируется на /root

а если
nfsroot=192.168.0.1:/nfsshare/images root=nfs:/image1.squash
тогда 192.168.0.1:/nfsshare/images должно быть смонтировано куда-то не в 
/root, а дальше пусть разбирается "squash-boot" со своим параметром 
root=, который она поймёт как процессить


Кстати, в каком объёме нужна будет поддержка NFS?
tcp/udp? v. 3 / 4? kerberos?



>> Если закомментить упоминания syslog:
> А куда у тебя логи идут в этом случае ?

Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно..
Cейчас с сетью, мне кажется нужно думать за ремотные сислоги.

Вот, говорят, busybox'ный syslog вроде как умеет отсылать:
https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging

И у меня есть смутная идея - возможно удалось бы экспортировать по сети 
/dev/log какой-нибудь хитрой магией netcat/socat