The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Проект MOOL развивает средства разработки драйверов ядра Lin..., opennews (ok), 04-Окт-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


75. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +1 +/
Сообщение от angra (ok), 04-Окт-14, 19:22 
Хмм, да также как и в С - операция присваивания переменной(находящейся в памяти по этому адресу) константного значения. Или вы из тех, кто плодит говнокод, насыщенный магическими числами и копипастой?
Ответить | Правка | Наверх | Cообщить модератору

90. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +/
Сообщение от Аноним (-), 05-Окт-14, 08:56 
> Хмм, да также как и в С - операция присваивания переменной(находящейся в
> памяти по этому адресу) константного значения.

Так в сях можно указать что вон та переменная - это вот тот адрес.

> плодит гoвнокод, насыщенный магическими числами и копипастой?

Весь код работы с периферией - куча магических чисел. Сюрприз. Правда культурные люди назначают им человекочитаемые определения, но сама по себе возможность сунуться в конкретный адрес памяти - фича сей, там указатели это просто адрес в памяти. Что и позволяет достаточно человекочитаемо работать с магическими адресами и магическими значениями в них. А в питонах и рубях такое изначально вообще не предусмотрено. Там нет никакого метода указать что "а вот эта переменная должна лежать по этому адресу". Да и вообще смысл высокоуровневого ЯП как раз в том чтобы програмер таким себе мозг не грел. Но это обрубает низкоуровневые возможности. По каким-то таким причинам все мало-мальски живые системы писаны на сях. Лучше за столько лет все-равно ничего не сделали.

Ответить | Правка | Наверх | Cообщить модератору

100. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +/
Сообщение от Я (??), 05-Окт-14, 20:21 
>Лучше за столько лет все-равно ничего не сделали.

http://en.m.wikipedia.org/wiki/Oberon_operating_system
http://www.a2.ethz.ch/

Ответить | Правка | Наверх | Cообщить модератору

105. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  –1 +/
Сообщение от angra (ok), 06-Окт-14, 00:14 
> Весь код работы с периферией - куча магических чисел. Сюрприз.

Нет, не сюрприз. Также как не сюрприз, что ты не знаешь значения термина "магические числа" в отношении патернов программирования.
Правда культурные
> А в питонах и рубях
> такое изначально вообще не предусмотрено. Там нет никакого метода указать что
> "а вот эта переменная должна лежать по этому адресу".

Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав?
> вообще смысл высокоуровневого ЯП как раз в том чтобы програмер таким
> себе мозг не грел. Но это обрубает низкоуровневые возможности.

С какого перепугу добавление одной возможности обрубает другие? Скажи честно, что в Perl/Ruby/Python не разбираешься.

Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

110. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  –1 +/
Сообщение от Аноним (-), 06-Окт-14, 04:42 
> термина "магические числа" в отношении патернов программирования.

Я его знаю в значении программирования периферии, в данном контексте этого достаточно.

> Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав?

Действительно, показали - турбокостыль, с реверансом в сторону си. Если уж на то пошло - проще не выделываться и сразу на си писать. Там это симпатичнее выглядит как текст, не требует интерпретера на несколько мегов и вообще компилится в пару машинных команд. Понятно что при сильном желании закостылить можно все. А вон жабисты в ведроиде через JNI дергают нативный код. Только это геморрой на ровном месте неизвестно ради чего.

> С какого перепугу добавление одной возможности обрубает другие?

Скорее, такие возможности для высокоуровневых ЯП - как собаке пятая нога, т.к. высокоуровневые ЯП делаются чтобы уйти от низкоуровневых/платформоспецифичных деталей как раз и оперировать всякими высокоуровневыми абстракциями, не заморачиваясь техническими деталями. Если этого не получается - от высокоуровневого ЯП будет больше вреда чем пользы.

> Скажи честно, что в Perl/Ruby/Python не разбираешься.

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

Ответить | Правка | Наверх | Cообщить модератору

114. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +/
Сообщение от Аноним (-), 06-Окт-14, 05:36 
> Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав?
>Действительно, показали - турбокостыль, с реверансом в сторону си. Если уж на то пошло - проще не выделываться и сразу на си писать.

"Слив защитан!"(С)LOR

>Там это симпатичнее выглядит как текст,

Смотри ещё раз, мееееедленно:

import ctypes
g = (ctypes.c_char*N).from_address(addr)
sensor_staus = g[0]  # read the first byte

Это выглядит не симпатично и не понятно? А ты не дворник ли случайно? А то мало ли ...

>не требует интерпретера на несколько мегов и вообще компилится в пару машинных команд.

Не передёргивай. Я сразу написал что для писания ядерных модулей и драйверов - С идеален. До сих пор. Период. Ъ. Ы.
Но ты же сам перешел на опрос датчиков \ управление светодиодами :) А тут уже по всякому может оказаться. Для чего большого я бы сочинил С-ный модуль и говорил бы с ним из питона\ватэвэр_ю_дрчш_он лангуаге :) Для мелочи, ну там светодиодами моргнуть - см. выше :)

>Понятно что при сильном желании закостылить можно все. А вон жабисты в ведроиде через JNI дергают нативный код. Только это геморрой на ровном месте неизвестно ради чего.

Ну напиши андрод апп на сях 8-) посмотрим что ты после _этого_ начнёшь считать гиммороем и костылём :)

...

>Скорее, такие возможности для высокоуровневых ЯП - как собаке пятая нога, т.к. высокоуровневые ЯП делаются чтобы уйти от низкоуровневых/платформоспецифичных деталей как раз и оперировать всякими высокоуровневыми абстракциями, не заморачиваясь техническими деталями. Если этого не получается - от высокоуровневого ЯП будет больше вреда чем пользы.

Утипуси :) Посмотри что в 3.17 кернеле горячий финский парень вытворил :) Всю твою религию низверг :) Теперь с куску памяти можно лезть ч\з ... файловый дескриптор ... чуешь куда ветер дует ? :) Пока оно конечно неведомое нечто, на ведь допилят.

> Скажи честно, что в Perl/Ruby/Python не разбираешься.
> А чтобы на этом писать операционки или системные тулзы - надо серьезно ушибиться, имхо.

ОС - лучше не надо, тут я с тобой союзен, а системные тулзы ... на них и пишут. Или давай определения о чём это ты?

Ых, вот как то так :)

Ответить | Правка | Наверх | Cообщить модератору

138. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +1 +/
Сообщение от Аноним (-), 06-Окт-14, 19:10 
> Это выглядит не симпатично и не понятно? А ты не дворник ли
> случайно? А то мало ли ...

Ну да, декларация в 3 раза длиннее чем на чистом си, бинарное значение загнать - почти в 2 раза больше дряни вокруг, с кавычками какими-то. А так все замечательно. Ну и нафига там нужен ваш питон, если работа с периферией в основном в чем-то таком и заключается?

> Но ты же сам перешел на опрос датчиков \ управление светодиодами :)

Я вроде вообще про датчики и светодиоды не говорил. Скорее про memory mapped периферию и то что вокруг - программирование оной в основном и состоит из кучи черной магии с засылкой магических значений и всяких там данных в разнообразные магические адреса.

> бы сочинил С-ный модуль и говорил бы с ним из питона\ватэвэр_ю_дрчш_он
> лангуаге :) Для мелочи, ну там светодиодами моргнуть - см. выше :)

Не очень понимаю чего такое "большое" должно быть в работе с периферией. Это должно быть уже где-нибудь в прикладухах, etc. У питона к тому же дикие проблемы с скоростью работы. Так что такая "работа с периферией" будет весьма неторопливой если по пути попадется кусок питонятины. Там конечно есть всякие нестандартные урезки, рвущие зад чтобы это исправить, но в целом это больше похоже на борьбу с искусственными трудностями. А разучивать два наглухо разных ЯПа (что общего у си и питона?) - вообще извращение для утонченных ценителей.

А еще - на сях можно оформить либу которую потом можно дергуть откуда угодно. И из питона, и из жабы и откуда там еще. А вот здоровый шмат на питоне - не реюзабелен ни для кого кроме любителей питона. Ну и с другими высокоуровневыми ЯП такая же фигня - биндиться друг к другу высокоуровневые ЯПы не умеют, что сильно снижает реюзабельность кода.

> Ну напиши андрод апп на сях 8-) посмотрим что ты после _этого_
> начнёшь считать гиммороем и костылём :)

Да вообще-то гугле игроделы мозг сгрызли (т.к. для них гимор и костыль - именно ява) и теперь там есть и native sdk. Просто черезж-пно и не очень совместимо с другими. Хотя игроделы c SDL и OpenGL не очень ругаются теперь - там почти без изменений уже. Но например портануть кутевую программу - уже гимор. Что-то такое и бывает когда случается rampant layering violation и базовые компоненты делают слишком высокоуровневыми. Так что фиг с два вы на вашем бидоне поюзаете гуй на жабе без каких-то сильно отдельно турбокостылей. А была б низкоуровневая часть виджетов на си или хотя-бы плюсах - ну вон GTK+ к куче всего биндится, да и куть тоже.

> Всю твою религию низверг :) Теперь с куску памяти можно лезть
> ч\з ... файловый дескриптор ... чуешь куда ветер дует ? :)

Можно. И чего? А еще там сто лет как был доступ к всей памяти ядра через файл. Сто лет есть mmaped файлы, которые тоже "память как файл" и прочее. Только вот работа с памятью как файлом имеет кучу оговорок и программить так периферию мало какой псих захочет. А запилено это было под kdbus. Который сам по себе вообще не о работе с периферией и прочим.

> Пока оно конечно неведомое нечто, на ведь допилят.

Допилят до чего? Работать с памятью как файлом - достаточно утонченное извращение. А, гм, в чем "улучшение" когда мы ушли от работы с масссивом к работе с файлом? Это вообще ни разу не проще и имеет кучу особенностей. Периферия может быть чувствительна к таймингам и атомарности доступа, тогда как файлы изначально подразумевают произвольный доступ. Оформлять все это как файловые операции - уйма головняка на ровном месте.

> ОС - лучше не надо, тут я с тобой союзен, а системные
> тулзы ... на них и пишут. Или давай определения о чём это ты?

Относительно низкоуровневая обвязка - системные утилиты, etc. То что на этом пишут всякую системную автоматизацию на 1 раз, где скорость пофиг, а руками еще дольше - да и фиг с ним. Плохо когда на таком пишут относительно фундаментальные и долговременные вещи типа пакетных менеджеров. У знакомого гентуйца система портажей отпадала потому что питон не тот. А у убунтуев на половине систем апгрейдер обcиpaется. По все той же причине. И вот это - плохо, да. Хотя апдейтер все-таки системная автоматизация на 1 раз, но все-равно не здорово что он отпадает - переключать репы руками вместо этой "автоматизации" - позор таким автоматизаторам, имхо.

Ответить | Правка | Наверх | Cообщить модератору

140. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +/
Сообщение от angra (ok), 06-Окт-14, 20:05 
Пока ты совсем не ушел в мир фантазий напомню тебе с чего началось:
>Ну и как в каком-нибудь бидоне будет выглядеть присвоение адресу 0x100500 значения 0xDEADBEEF?

Тебе показали как, чего тебе еще? Если не можешь объяснить словами, то покажи свой вариант на С.
А главное заметь, никто не говорил, что питон это хорошо для ядра, это ты сам выдумал и героически опровергаешь.

Ответить | Правка | Наверх | Cообщить модератору

181. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."  +/
Сообщение от Аноним (-), 08-Окт-14, 07:00 
> покажи свой вариант на С.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру