А откуда у них берутся не-ASCII?

Однако, в архиве ядра версии 4.10 442253 байта находтся за пределами ASCII, 6220 из них относятся к *.c и *.h файлам, а 433693 - к документации. Всего *.c и *.h файлов, которые выходят за пределы ASCII, - 1150, при общем количестве 42422. Т.е. меньше чем 3%. При этом общее кол-во байт выходящих за границы ASCII не превышает 282 на файл. Рекордсменом с этими 282-мя байтами является файл drivers/scsi/qla4xxx/ql4_fw.h. На втором месте такие файлы как lib/fonts/font_8x16.c, lib/fonts/font_7x14.c, lib/fonts/font_8x8.c, lib/fonts/font_pearl_8x8.c в которых по 128 байт, которые выходят за пределы ASCII соответственно. На третьем месте файл include/video/display_timing.h в котором 126 байт за пределами ASCII.

Вот скажи, ты шизофреник, просто наркоман или придуриваешься?

Актер, страдающий шизофренией и зависимый от наркотиков

ASCII-nazi

.

Я посмотрел, там в этом ql4_fw.h код вида

struct ql_iscsi_stats {
        uint64_t mac_tx_frames; /* 0000–0007 */
        uint64_t mac_tx_bytes; /* 0008–000F */
        uint64_t mac_tx_multicast_frames; /* 0010–0017 */
        uint64_t mac_tx_broadcast_frames; /* 0018–001F */
        uint64_t mac_tx_pause_frames; /* 0020–0027 */
        uint64_t mac_tx_control_frames; /* 0028–002F */
        uint64_t mac_tx_deferral; /* 0030–0037 */
        uint64_t mac_tx_excess_deferral; /* 0038–003F */
        uint64_t mac_tx_late_collision; /* 0040–0047 */
        uint64_t mac_tx_abort; /* 0048–004F */
        uint64_t mac_tx_single_collision; /* 0050–0057 */
        uint64_t mac_tx_multiple_collision; /* 0058–005F */

В комментах юникодные тире

Заговор мировогo юникодизма.

saahriktu просто обязан заслать комит.

Они ещё мой прошлый багрепорт уже почти год молча рассматривают. Так и висит со статусом NEW.

Я просто могу проводить такие исследования. Кто-то же должен их проводить.

мой прошлый багрепорт

А где ссылка?

https://bugzilla.kernel.org/show_bug.cgi?id=114471

на сколько похудеет код если привести его к ASCII?

По ходу, меньше чем на 7 килобайт. При общем объёме кода в 566 мегабайт.

Эти исследования можно заскриптовать на баше или питоне.

Автор, пиши про каждую новую минорную версию ядра, это чертовски увлекательно.

С этим никто и не спорит. Вопрос выше был не про методы исследования, а про сами исследования.

Вопрос выше был вот о чём: что за шиза вас натолкнула на самую идею подсчитывать файлы в разных кодировках в минорном патче ядра?

подсчитывать файлы в разных кодировках в минорном патче ядра

Что-что?

Патч распространяется одним файлом. И он на 100% в ASCII. Вот я заодно и проверил архив 4.10 без учёта патчей целиком.

Проверил на что?

:D

Скорректируй все non-ASCII отдельным патчем. Делов-то.

Проверил на что?

На соответствие пределам ASCII.

Зачем?

Вещества в теги!

чем только люди не занимаются, лишь бы не работать

Зачем?

Полезная информация всегда полезна.

напоминают легендарного мужика, который в 70е годы написал письмо на Балабановскую спичечную фабрику. Мужик написал примерно следующее - «Я 11 лет считаю спички у вас в коробках - и то 59, то 60, а иногда и 58. Вы там сумасшедшие что ли все?»

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

Вы, похоже, окончательно обезумели.

https://bugzilla.kernel.org/show_bug.cgi?id=114471
I'm using

Runglish издалека видно.

А ещё по твоей ссылке нихрена (кроме ололо «I bumped into ... limitations») не написано про твою проблему.

Зачем приводить простыни если «PSF fonts» и «vt.c» уже более чем ключевые слова? В vt.c нет кучи разных параллельных подсистем для работы с PSF шрифтами. И там разработчики про эти ограничения написали явным образом сами:

/*
 *  Font switching
 *
 *  Currently we only support fonts up to 32 pixels wide, at a maximum height
 *  of 32 pixels. Userspace fontdata is stored with 32 bytes (shorts/ints,
 *  depending on width) reserved for each character which is kinda wasty, but
 *  this is done in order to maintain compatibility with the EGA/VGA fonts. It
 *  is up to the actual low-level console-driver convert data into its favorite
 *  format (maybe we should add a `fontoffset' field to the `display'
 *  structure so we won't have to convert the fontdata all the time.
 *  /Jes
 */

#define max_font_size 65536

Проблема не в моём багрепорте. Там со всеми соседними багрепортами в том разделе тоже самое. Все они там имеют статус «NEW», даже от 2012-го года. И это несмотря на то, что за разделом закрепляют конкретного человека.

Ты плохо понимаешь, что такое багрепорт. Багрепорт это самостоятельное произведение. Ссылки в нем имеют смысл только как подтверждение сказанного. Выискивать, что ты имел в виду, по ссылкам никто никогда не будет (разве что кто-то и так собирался твою проблему чинить, и ты просто угадал с темой «багрепорта»). К тому же у тебя не багрепорт, а feature request, а это еще понижает приоритет. Некачественный feature request — гарантия того, что его никогда не удовлетворят. Качество английского языка,кстати, тут ни при чем. К нему придираются в последнюю очередь.

Выискивать, что ты имел в виду, по ссылкам

Даже в случае грамотного и подробного текста всегда могут остаться вопросы, и без обратной связи тут никак. Собственно, я и ожидал, что мне зададут уточняющие вопросы. Но, нет. У них там совсем глухо.

Какой багрепорт, такая и реакция. Обижаться не на что. Ты не приложил усилий, не жди от других, что они сделают работу за тебя.

Кто-то же должен их проводить.

Вызывающе неверная информация.

I'm using

Runglish

What's wrong with that?

https://en.wikipedia.org/wiki/Ashkenazi_Jews

?

Уточнить вопросом всегда можно. Пришедший в багзиллу может и не быть программистом, и даже может и не смочь, в отличие от меня, показать на проблемный файл в исходниках, но при этом может иметь возможность описать проблему в общих чертах. И что, такие случаи тоже никто не рассматривает что-ли? Разработчики, как правило, сами заинтересованы в качестве кода, а потому им ценна любая информация. При этом, подчёркиваю, хорошие разработчики и так знают что они делают. В случае больших проектов с участием большого кол-ва людей, конечно, может быть всякое. Может быть и так, что закреплённый за той или иной подсистемой разработчик не помнит её код наизусть, да. Но, всегда можно уточнить. Пришедший в багзиллу не обязан думать о степени осведомлённости закреплённого за разделом человека, тем более что он остаётся на связи.

Перед тем как запостить своё я читал багрепорты в том разделе, и они ни разу не подробнее. Вот чем, например, плох следующий багрепорт?

I've crafted a .psfu console font that include the 256 Unicode braille patterns (https://github.com/NodeOS/NodeOS/tree/m
aster/node_modules/nodeos-rootfs/node_modules/nodeos-console-font) to use them for graphic purposses on the console (htt
ps://github.com/asciimoo/drawille), and I want to use it as default font (compiled in kernel) because it will be used in
 a minimalistic, ready-to-use barebones system combining Linux kernel and Node.js (https://github.com/NodeOS/NodeOS).

Since I want still be able to use ASCII characters, this makes it a 512 glyphs font, but after some tests and code look-
outs, I've found that Linux kernel and build tools has hard-coded the usage of 256 glyphs in default fonts (https://gith
ub.com/torvalds/linux/blob/718749d56214aa97015fe01b76b6d6dd0c171796/drivers/video/console/fbcon.c#L998 and http://lxr.fr
ee-electrons.com/source/scripts/conmakehash.c#L107), and in fact seems that has set to explicitly only test for the actu
al number of glyphs for user loaded fonts in several places

https://github.com/torvalds/linux/blob/718749d56214aa97015fe01b76b6d6dd0c171796/drivers/video/console/fbcon.c#L2453-L245
6
https://github.com/torvalds/linux/blob/718749d56214aa97015fe01b76b6d6dd0c171796/drivers/video/console/fbcon.c#L2574-L257
7
https://github.com/torvalds/linux/blob/718749d56214aa97015fe01b76b6d6dd0c171796/drivers/video/console/fbcon.c#L3226-L322
7
https://github.com/torvalds/linux/blob/718749d56214aa97015fe01b76b6d6dd0c171796/drivers/video/console/fbcon.c#L3240-L324
1

but I think there's no actual a hard requeriment (hardware support or similar) that would not allow to use them, since i
n fact user loaded fonts can use 512 glyphs.

Another alternative is to use setfont command, but it's not only giving me problems to compile it (NodeOS is a musl-base
d system, it don't use glibc) but also would complicate the usage of the system since in it's basic form it show to the
user a Node.js REPL, similar in concept to 80's microcomputers BASIC prompt.

Also I have been thinking about fixing it myself, but don't have enough time at this moment (at least until Summer). I t
hink the first step is to change conmakehash to allow more than 256 glyphs in the generated code, and later update fbcon
.c to be able to manage them for default fonts (probably mostly to use the same macros to check the font size that are b
eing used for user loaded fonts).

городской лоровский сумасшедший, без подобных ему - лор не торт

кучу раз слышал I'm using от нейтивов

Кто-то же должен их проводить

Ты в этом уверен?

А как ещё определить границы возможностей как не исследованиями?

Это хороший багрепорт (ну или тоже скорее feature request). Но не твой же. Или ты пытаешься оправдать плохое качество своего репорта тем, что и хорошие лежат без движения? Ну так должен сам понимать, что в этом случае у твоего репорта вообще никаких шансов.

Ну как-то так, да

А что не так?

Вероятно, I use.

да, почти всё

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

Вот чем, например, плох следующий багрепорт?

Всем хорош. Сойдёт для докторской по психическим расстройствам. Спектрум-алайк на нодежс с брайлем вместо шрифта, не, мне бы столько не выпить.

Полезная информация всегда полезна

Это да. А на ASCII—то зачем проверять?