> Кто и как будет определять, что и как часто нужно опрашивать?

По нормальному - сделать параметром который можно заказать. Если клиент X хочет 1 раз в секунду, а клиент Y хочет 2 раза в секунду, читаем 2 раза в секунду, но одному отдаем все отсчеты а второму через один. А если они это будут делать независимо, в хучшем случае они будут дергать датчик не 2 а 3 раза в секунду.

> Несогласен - всё железоспецифичное - драйверу.

Это идеальный случай. Реально совсем ничего не знать о свойствах железки, пределах измерений, максимальной частоте измерений и прочая - юзермоду может быть тяжко.

Вот вижу я аксель. А вот я у меня игрушечный вертолетик которым я порулить с смарта хочу, используя этот аксель. Как мне в программе понять - годятся ли хоть в первом приближении параметры акселя? Это таки специфика железки и драйвера, но их было бы неплохо узнать. В плане диапазонов значений а также скорости и латенси получения отсчетов.

> все на уровне sysfs?

Делать из ФС шину - ну совсем не просто. Как максимум получится кривой франкенштейн. Оно годится как некая low level подложка, но для обычных апликух с ним довольно много мороки, особенно когда вопрос в том "а какие градусники есть и что они показывают?".

> любом случае будет overhead. Вы же не согласитесь с обычной файловой
> системой работать через d-bus? Так сказать в целях унификации интерфейсов ;)

Мне кажется переклин на тотальной унификации интрфейсов - ведет к контрпродуктивным запрыгам по граблям, когда гвозди начинают завинчивать отверткой. В целях унификации.