В модуле ядра для включения вайфай имеется следующая процедура:
static int amiloa1655g_proc_init(void)
{
struct proc_dir_entry *ent;
int err = 0;
dir_base = create_proc_entry(DRV_NAME, S_IFDIR, &proc_root);
if (dir_base == NULL) {
printk(KERN_ERR DRV_NAME ": Unable to initialise /proc/"
DRV_NAME "\n");
err = -ENOMEM;
goto fail;
}
ent = create_proc_entry("radio", S_IFREG | S_IRUGO | S_IWUSR,
dir_base);
if (ent) {
ent->read_proc = proc_get_radio;
ent->write_proc = proc_set_radio;
} else {
printk(KERN_ERR
"Unable to initialize /proc/" DRV_NAME "/radio\n");
err = -ENOMEM;
goto fail;
}
return 0;
fail:
amiloa1655g_proc_cleanup();
return err;
}
Модуль работает отлично, однако смущает наличие конструкции goto. Нужно ли избавиться от нее и если да то как это лучше сделать?
Да переделать-то несложно. Две строчки под меткой fail поставить вместо goto в оба if. Только надо ли? Будет у функции три точки выхода размазанных по всему телу, вместо двух рядом в конце. По-моему это хуже чем использование goto.
вот что лично меня смущает, так это использование "забитых" в код значений, вроде
ent = create_proc_entry("radio", S_IFREG | S_IRUGO | S_IWUSR,dir_bas);
^^^^^^^
дефайны и то приемлимее.
Можно подробнее про х*рение конвеера при гото? Я думал что конвеер может х*риться при условном бранче, а не при безусловном. Безусловный максимум дополнительную нагрузку на kэш создает?
> Я думал что конвеер может х*риться при условном бранче, а не при безусловном.
Я не специалист в этом вопросе, просто озвучил многократно прочитанное.
Безусловный переход не имеет структуры. Поэтому для его предсказания надо рассматривать не только контекст _откуда_ этот переход делается, но и контекст того, _куда_ он делается. А он может быть сделан куда угодно, в том числе и внутрь цикла.
> Одно надо помнить -- в суперскалярных процессорах goto херит все конвейеры...
По моему Вы путаете с предсказанием ветвлений, которое на условных переходах не всегда работает как надо. goto это просто jmp, который совершенно не влияет на это.
goto вреден при машинно-независимой оптимизации программы,
то есть программа использующая только уловные циклы и ветвления
без goto,setjmp и exception лучше поддаётся автоматизированной оптимизации по быстродействию или объёму памяти. Где-то лет д`цать назад была очень модна такая вещь как теория схем программ,которая как-раз и была посвещенна оптимизации и распараллеливанию. Один из выводов теории: Длинный или непредсказуемый goto херит наглухо любой метод.
goto не может быть непредсказуемым. При правильном использовании goto может сам по себе являться элементом оптимизации. Попробуй переписать amiloa1655g_proc_init() без goto сравни как его оптимизирует компилятор.