[patch] set argv[0] of init process to filename

Glenn McGrath (bug1@optushome.com.au)
Thu, 8 May 2003 14:54:12 +1000


This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-31133-1052369584-0001-2
Content-Type: multipart/mixed;
boundary="Multipart_Thu__8_May_2003_14:54:12_+1000_081a3070"

--Multipart_Thu__8_May_2003_14:54:12_+1000_081a3070
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In init/main.c the kernel always sets argv[0] = "init" when calling the
init process.

The file being executed as init is commonly /sbin/init, but could be
anything, as set from init= boot paramater.

Always setting argv[0] = "init" is inconsistent with standard behaviour
of setting it to the filename that was run.

This current behaviour is inconvenient for busybox (www.busybox.net) as
it uses argv[0] to determine functionality.

The attached patch against 2.4.20 sets argv[0] to the filename being run
as the init process, it results in marginally smaller binary (12 bytes).

Is there a reason why argv[0] should always be set to "init" ?

Glenn

--Multipart_Thu__8_May_2003_14:54:12_+1000_081a3070
Content-Type: application/octet-stream;
name="init_argv.diff.gz"
Content-Disposition: attachment;
filename="init_argv.diff.gz"
Content-Transfer-Encoding: base64

H4sICFjbuT4CA2luaXRfYXJndi5kaWZmAJVU207bShR9tr9iNy914kt8IUBBkegDOqXiIrWc6kgV
spzJBI9iz1gz4wSE+PezZxyTQIra+sHXfVlr7bUdhiFUjLcPYRodRGk8ZpzpcV0wHhEnjeM0jI/D
OIMkPsk+nRwcRnF/gJ/g2fV9/1WBqGacvq2ShfEEC0GSnBwcnSTHe1XOziBMkuPgEz7j5QjOzlxw
gXENUqxVAERU6hRfhaQsJIzoAyWtpjkRdV3w+akbuqHShWYEugAo5P0qNzB+Xn3+L7+4vrjNP3/7
57uf3sEUnmBgPg0CuP738jKA51PX/6v0Ls2cTW6fRPmqeZN0fv1j2/PLzdX5dIxdB7fn366mVrZd
DMh4g8IQz20paKRYsIrmiuq28bpOSsuh1SzNMhTLT7PkRTOHLcD7MMLidIhPjsQ8yVEhBzkpBBIj
2f4+waYOwu7unfEIDDJgCrAdaAEfLciPMHuEOV0UbaVhNMYcTh805pgupsS6RIjgeeYZX5uvQ/gw
tdSG8NRhnWRBkiHYSWKuBu17x8gUQGNZsMjBUkLSnNSN7RHY+U0HwWRoymOIY1v7U5gYqo7zxiEv
WH38th1ufLdDwjH8LziQQlG4vLi8MTrcC8bvjRIzITS0CtZMly9a9NUtJlsCbWCHRhvK5woGRavF
AGZ0ISQFXVJYlwKlIvXcAkbhSAl1saSqTzdBqqRVhXeML005VYq2msOGExSgiGSN7rCoFivwoqZR
X+G7gDUFds9NzwILIeG2plwrtKimks4h7xDlYHWMogh+Xn292xQYWwV37eK8MozjEME1GqOT7bkf
ESkpWXY+tfbrPDo5iIND8CfZcZCkG5PieKnksBJsbrUqEIqhoJqCUM+8Hpp16JfSxsmW26HluBGE
KuX98lcwdP2nzt+7I977X/jWICvqvfkSbDc/2O4zgvGfXf/Vepr3FikK3vJWUWxtrVgJssyXSI9W
HiZaCQ6Re4IaHKW9BnbS8nFjLkmJWFGJk5UUB/YIMymWlKMxCHrATtbuHQ7GCL3HOXTe47Ols8sm
7MMHYzVjfNz9DX8bSzX509C/qGpCVfleoG8Z787TbDxacs8Pr2JMIo5sP2qXsY36RcQLz/cCflth
w8m42GkKzog3uBbWM7AQLZ9HALfyEZpCKWMBu4UgGs0EN37o7BPZ/Gf3fxDHUO2lBwAA

--Multipart_Thu__8_May_2003_14:54:12_+1000_081a3070--

--=_courier-31133-1052369584-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ueL/WWZyfXiLlL8RAvszAJ9LuLcxMHqKWd9LHvG5r1+saanm1gCdHGFM
RSKFILkwqf59Yg0eYqGleOs=
=0ItS
-----END PGP SIGNATURE-----

--=_courier-31133-1052369584-0001-2--