Ні, липкий біт не був схожим на прапори set-UID або set-GID. Це не змінило жодних змін для обробки облікових даних.
Те, що було зроблено, було зробити текст програми "липким". Спочатку це не було помилкою.
фон: розділи програмного зображення та спільний текст
По суті, не надто заглиблюючись у деталі виконуваних форматів файлів (які можуть і мають заповнені книги): частини файлів зображень програми, які безпосередньо завантажуються в пам'ять для запуску програм, включають машинний код, константи, запуск. значення змінних (не-нульові ініціалізовані) та (в тій чи іншій формі) порожні пробіли для нульових ініціалізованих та неініціалізованих змінних.
Вони згруповані в колекції, відомі як "секції", і вони мають умовні назви. Машинний код та (іноді) константи утворюють те, що часто називають розділом "текст" програмного зображення. Неініціалізовані змінні (ненульові) - це також розділ "дані"; а нульові ініціалізовані та неініціалізовані змінні - "bss" (назва, яке саме за собою має цілу фольклорну історію).
Якщо у процесі завантажений у нього програмний файл зображення, то різні частини - текст, дані та bss - ініціалізуються зі вмісту файлу зображень.
Що в розділі "текст" є особливим, це те, що машинний код (і константи) майже завжди не пишеться на. Він має потенціал для спільного використання зображень віртуальної пам’яті всіх виконуваних процесів, у яких завантажений у них виконаний файл зображення. Точний сценарій, в якому можна поділитись текстом програми, виходить за межі цієї відповіді і включає такі речі, як ідентифікація налаштування завантажувача та ідентифікація макета адресного простору. Люди можуть і писати книги з цього приводу теж. ☺
Спільний текст - це оптимізація, яку використовує ядро. Він усуває необхідність кожного екземпляра одного запущеного програмного зображення мати власне індивідуальне зображення пам’яті, споживаючи дорогоцінну фізичну пам’ять з декількома копіями точно такого ж машинного коду (та констант).
липкий текст
Але все-таки можна зробити краще, ніж спільний текст. Очевидно, що якщо завжди працює хоча б один процес, що використовує певний образ спільної текстової програми, ядро отримує просто приєднати віртуальний простір нової пам’яті нових процесів до наявного сегменту загального тексту, коли запускається новий екземпляр програми. Майже завжди існує екземпляр (скажімо) /bin/loginабо /bin/shпрацює десь у середньому розмірі системи, тому нові екземпляри програми входу або оболонки за замовчуванням можуть просто приєднати до завантажених копій своїх текстових сегментів, які ядро вже завантажило в пам'ять.
Клейкий текст поширює цю ідею на програмування зображень, які зараз не виконується жоден процес . Якщо виконуваний файл зображення позначений як липкий текст, то ядро зберігає свій текстовий сегмент навколо останнього процесу для його використання; сподіваючись, що незабаром буде запущений інший екземпляр програми, і він може просто приєднатися до сегмента.
У ранніх Unices завантажені липкі текстові сегменти будуть замінені для обміну сховищами, коли до них не додається жоден процес. (Пізніше Unices перестали використовувати swap для цього.) Можливо, ви також чули про це за текстом, збереженим назвою .
Звичайно, встановлення клейкого текстового біта на програмне зображення - це те, що потрібно обережно робити. Які програми від цього виграють, залежать від того, для чого машина зазвичай використовується. Наразі неприєднані текстові сегменти займають ресурси ядра, це означає, що існує практичне обмеження на кількість їх у будь-якій системі. Тож це, як правило, операція, яка вимагає привілеїв суперпользователя.
дезует
Існує цілий набір припущень, що лежать в основі роботи липкого тексту, які вже більше не відповідають дійсності. Читання заздалегідь зробленого сегмента із сховища своп не обов'язково швидше, ніж просте запитування на вимогу з фактичного виконуваного файлу зображення. Формати файлової системи стали кращими для випадкових (на відміну від послідовних) шаблонів читання. З'явлення підкачки попиту сама по собі змінює речі, як і такі речі, як уніфіковані кеші, неімпотентні зовнішні виправлення, що виникають внаслідок відмінностей у спільному пошуку бібліотеки та рандомізації компонування простору адрес.
Часи липких текстових бітів для зображень виконуваних програм давно минули. Наприклад, явний липкий прапор маркера тексту для зображень виконуваних програм вважався застарілим, наприклад, в середині 1980-х авторами 4.3BSD.
Подальше читання
- Моріс Дж. Бах (1986). Дизайн операційної системи UNIX . Prentice-Hall. ISBN 9780132017992.