> Проверялся. =)ну а результат какой ? ;))
отлично.
тогда, предположим, что API драйверов некого ядра содержит 3 вызова.
Так, для наглядности.
Давай на таком API подымем самое простое - линуховый ext2.
вот структура его операций:
static const struct super_operations ext2_sops = {
.alloc_inode = ext2_alloc_inode,
.destroy_inode = ext2_destroy_inode,
.read_inode = ext2_read_inode,
.write_inode = ext2_write_inode,
.put_inode = ext2_put_inode,
.delete_inode = ext2_delete_inode,
.put_super = ext2_put_super,
.write_super = ext2_write_super,
.statfs = ext2_statfs,
.remount_fs = ext2_remount,
.clear_inode = ext2_clear_inode,
.show_options = ext2_show_options,
#ifdef CONFIG_QUOTA
.quota_read = ext2_quota_read,
.quota_write = ext2_quota_write,
#endif
};
итого, с квотами это 14 вызовов.
ТеперЪ мы имеем делеммму:
- пойти простым путем и постоянно передавать указатель на эту структура-монстра через какой-нить доп. параметр имеющегося API, либо
- все-же изменить API, учтя требования для _человеческой_ реализации подобной сложности файловых систем. Потому как вдальнейшем нам захочеться добавить такую не одну (jfs, reiser, lustre....)
Каким путем пойдем, тАварищи??
Пример с API на 3 функции и задачей реализовать 14 можно легко экстраполировать в
рекущие размеры API и то, что может быть придумано в будущем.
Кому-то еще непонятно, что изменения API - это нормальный процесс?
Вариант для распечатки
(??), 29-Сен-07, 21:19 
