Ting 이네 Software 이야기

To use sysfs, enable kernel config : CONFIG_GPIO_SYSFS
Core files related with this : gpiolib.c at Kernel
sysfs nodes can be found at /sys/class/gpio

[ Prerequisite ]
writing value to '/sys/class/gpio/export' uses 'gpio_request()' function at gpiolib in kernel.
So, if given gpio is already requested by other owner, exporting is failed.
Therefore, gpio should not be owned by others in kernel to control gpio at user space.

[ How to use at user space ]
Assumption : current working directory is '/sys/class/gpio'

#> echo [gpio num] > export
=> export give gpio to sysfs. gpioN link is newly created if gpio number is valid one.

#> cd gpioN
=> Then, several nodes (active_low, direction, value etc) can be found.
Writing or reading following nodes, is one of useful way to debug/control gpio at user space.
(attribute functions for each node are defined at gpiolib.c)

[ Detail Example ]

* at /sys/class/gpio
export, unexport : gpio number
#> echo 86 > export
#> echo 86 > unexport

* at /sys/class/gpio/gpioN
direction : in, out, low, high
value : 0, 1
edge : none, rising, falling, both
active_low : 0, 1
#> echo in > direction
#> echo 1 > value
#> echo both > edge

< See gpio.txt of Kernel document for details about each sysfs node. >

Linux kernel uses lot's of sections to modularize it's code structure easily.
In case of kernel module and parameter, following section is used.

[ Module ]
macro   : module_init()
section : device_initcall (section name : .initcall6.init) <see init.h>

[ Parameter ]
macro   : module_param_named(), module_param(), core_param() etc.
section : __param <see moduleparam.h>

core_param() macro works like other module parameter. But this is NOT for module BUT for kernel booting parameter.
Kernel parameter doesn't have any prefix unlike other modules.
Module parameter's name has <module name> as it's prefix.
For example, parameter <param> of module <module> has name <module>.<param>
See source code for details.

KBUILD_MODNAME is preprocessor value for module name.
This is defined through complex script processing. See Makefile.lib, Makefile.mod* in scripts/.
But in most case, you can know it by intuition. That is,  name that seems like module name, is set as KBUILD_MODNAME.
(ex. <mod name>-y, <mod-name>-m in Makefile)
So, usually, deep analysis about above scripts are not required.

Note:
It's possible that one object gets potentially linked into more than one module.
In that case KBUILD_MODNAME will be set to  foo_bar, where foo and bar are the name of the modules.

Module and parameter initialization.

[ Built-in module ]
module initialization : do_initcalls() <see 'main.c'> => initcall section is used
parameter sysfs node  : param_sysfs_init() -> param_sysfs_builtin() => __param section is used

[ Dynamic module ]
module & parameter initialization is done at system call
SYSCALL_DEFINE3(init_module, ...) => load_module()

Each parameter has permission mask. So, parameter value can be read or written at runtime through sysfs node.

/sys/module/<module name>/parameter/<parameter name>

But module parameter whose  permission is 0, is ignored at sysfs (Not shown at sysfs).
( See module_param_sysfs_setup(...) function. )

[ SW 엔지니어에 대한 잘못된 생각들 ]

SW를 잘 알지 못하는 사람들이, SW 엔지니어에 대해 이야기 할때 일반적으로 범하기 쉬운 몇가지 오류들에 대해서 짚어보고자 한다.

* SW엔지니어는 일정을 이야기할때 굉장히 보수적인 일정만을 말한다.

음... 일부러 일정을 늘려서 이야기하는 엔지니어도 분명히 존재한다.
그렇지만, 그런 경우는 엔지니어의 태도문제도 존재하지만, 조직의 분위기에도 문제가 있다고 보는게 옳다.
estimation한 일정을 지키지 못했을 경우 - fix된 일정이 아니라 estimation한 일정임에도 불고하고 - '실패'로 몰아세우면서 질책하는 문화에서는 보수적인 일정을 제시할 수 밖에 없기 때문이다.
이런 '책임 회피성 일정'을 논외로 한다면, 엔지니어들은 일정을 굉장히 aggressive하게 제시하는 경향이 오히려 강하다.
왜냐하면, 일에 대한 구체적인 분석이 없는 상태의 초기 estimation은 항상 여러가지 사항들을 놓치게 마련이고, 따라서 실제 일의 양보다 적은 양을 예상하기 때문이다.
그래서, "실질적인 일정 = 엔지니어의 예상 * 2"라는 우스겟 소리도 있다.
따라서, 필자는, 조직에서 SW엔지니어들이 보수적인 일정을 제시하는 경향이 있다면, 그것이 소위 '책임 회피성 일정'이 아닐까를 먼저 의심하고 그렇게 할 수 밖에 없게 만드는 조직의 문제점을 찾아서 제거할 필요가 있다고 생각한다.

* SW엔지니어의 생산성은 투입된 시간에 비례한다.

SW작업에서 물리적인 시간적 투자를 필요로 하는 일은 일부에 지나지 않는다. 대부분은 고도의 집중력을 요구한다.
대부분의 사람들이 위의 이야기에는 동의함에도 불구하고, SW엔지니어가 일한 시간에 관심을 가지는 이유는, 생산성을 측정할 수 있는 방법을 알지 못하기 때문이다.
그렇기 때문에 '시간 투자 = 성실/성과' 이라는 차선(?)책을 사용하고 있고, 이것이 생산성과 시간과의 관계에 대한 잘못된 생각을 퍼트리고 있다.

* 많은 버그를 잡는 사람은 뛰어난 SW엔지니어이다.

버그는, 수정하는게 중요한게 아니고, 만들지 않는 것이 중요하다.
이는 비단 초기 개발 단계만의 이야기가 아니다. 버그를 잡기 위해서 다시 버그를 만드는 과정을 반복하는 많은 미숙한 엔지니어들이 있다.
만약, 실제로 SW를 개발을 하는 팀이라면, 버그에 관계된 성과 측정기준은, 반드시 "발견된 버그의 개수"가 되어야기 "수정한 버그의 개수"가 되어서는 안된다.
이는 유지보수팀에서도 일정부분 적용되는데, 유지보수팀에서는 "버그를 수정한 수"에 앞서 "fix-on-fix"의 수에 더 많은 가중치를 주어야 할 것이다.
넘치는 fix-on-fix를 감당하지 못해서 commit자체를 revert하는 경우도 심심치 않게 일어난다.

* 디버깅을 잘하는 사람은 programming도 잘 한다.

'만류귀종'이라는 말처럼, 궁극에 이르면 두 가지 능력 모두 최고 수준을 보일 것이다.
그렇지만, 상당부분에서 디버깅과 programming은 서로 다른 skill을 요구한다.
필자의 post 중 여기 를 참조하자.

* 작성한 코드의 line수와 생산성은 비례한다.

정말 이 말을 맏는가?
무관하다고 말할 수도 없지만 - 1년에 1라인을 작성한 사람과 하루에 1000라인을 작성한 사람 - 그렇다고 해서 비례하지도 않는다.
너무 극단적인 경우를 제외하고는, 이것은 성과측정의 기준이 될 수 없다.

* 변수/함수의 이름을 바꾸기, 하나의 함수를 두개로 분리하기, compiler warning을 제거하기, 주석 추가/수정하기 등 실질적으로 코드의 동작과 무관한 contribute는 무의미하다.

이런 일들이 생산성과 무관하다고 생각하는 사람이 있다면, 음... 더 이상 필자의 글을 읽을 필요가 없다.
왜냐하면, 기본적인 믿음 자체가 다르기 때문이다.
필자가 보기에는, 이런 일들은 버그를 잡거나, 새로운 기능을 구현하는 것만큼 중요하다.
SW의 가독성을 높여서, 유지보수를 쉽게 하고, SW의 장기적인 건전성을 확보하는 일은 그리 가벼이 볼 일이 아니다.

* 뛰어난 SW 엔지니어는, 버그 및 수정 요구사항을 빠르게 해결해서 적용한다.

'속도'가 중요한게 아니다.
지나치게 빠르다고 생각되는 대부분의 수정은 다량의 'fix-on-fix'를 유발하는 경우가 많다.
'얼마나 빨리 하느냐?' 가 아니라, '얼마나 정확히 잘 하느냐?'가 중요하다.
빨리 했지만 결국에는 버려야 할 contribute보다는, 조금 늦게 진행되고 있지만 착실한 contribute가 가치가 있는 법이다.

기타 많은 것들이 더 있겠지만.. 일단 여기까지만... 생각나면 더 추가하도록 하겠다..